| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've had a few users who wouldn't (or couldn't) provide us btrfs-images because
we maintain the file names when making an image. So introduce a sanitize
option. There are two uses, one that is fast and the other that is dog slow.
The fast way just generates garbage that's equal in length to the original name.
The slow way will try and find a crc32c collision for the file name that is also
the same length. Finding a crc32c collision for the file name "btrfs-progs" on
my box without CPU crc32c support takes a little more than 3 minutes, and a
little less than 2 minutes for my box that has CPU crc32c support, so it's a
lengthy and CPU intensive process.
The idea is that we use -s for most cases, and then only use -ss when we need
the file system tree to be somewhat sane. I could probably do a better job
about finding collisions, but I'll have to revist that later. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When working with a user with a broken file system I noticed I wasn't able to
read some of the blocks properly from the restored image. This is because his
extent tree was corrupt and was missing references to some of the blocks, which
means they weren't copied into the image when he generated it. So add a -w
option which will walk all of the trees manually and copy them into the image.
This way we can run fsck against a complete file system image and fix any bugs
in fsck. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously btrfs-image would set a METADUMP flag and would make one big system
chunk to cover the entire file system in the super in order to get around the
unpleasant business of having to adjust the chunk tree. This meant that you
could use the progs stuff on a restored file system, which is great for testing
btrfsck and other such things. But we want to be able to run the tree log
replay on a file system that is not able to run the tree log replay. So in
order to do this we need to fixup the super's chunk array and the chunk tree
itself. This is pretty easy since we restore using the logical offsets of the
metadata, so we just have to set the chunk items to have 1 stripe and have the
stripes point at the primary device and then use the logical offset of the chunk
as the physical offset. With this patch I can restore a file system image that
had a tree log and mount the file system and have the log be replayed
successfully. This patch also gives you the -o option in case you want the old
restore way, in the case where we want to make sure the system chunks as they
were given to us are correct. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the commit 002d021c (committed October 2011)
btrfsctl, btrfs-vol, btrfs-show were declared deprecated.
The last patches related to these commands are dated December 2010.
These tools are replaced by the "btrfs" tool in all the
functionality.
This commit removes all the related code.
Signed-off-by: Goffredo Baroncelli <kreijack@inwind.it>
Signed-off-by: David Sterba <dsterba@suse.cz>
|
| | |
|
|
|
Signed-off-by: Peng Tao <bergwolf@gmail.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
|
