On Tue, Jan 29, 2013 at 02:41:08PM -0600, Eric Sandeen wrote: > The manpage for the "-r" option simply says that > it will copy the path specified to -r into the newly > made filesystem. > > There's not a lot of reason to treat that option as differently > as it is now - today it ignores discard, fs size, and mixed > options, for example. It also failed to check whether the > target device was mounted before proceeding. Etc... > > Rework things so that we really follow the same paths whether > or not -r is specified, but with one special case for -r: > > * If the device does not exist, it will be created as > a regular file of the minimum size to hold the -r path, > or of size specified by the -b option. > > This also changes a little behavior; it does not pre-fill > the new file with zeros, but allows it to be sparse, and does > not truncate an existing device file. If you want to start > with an empty file, just don't point it at an existing > file... Fixes numerous bugs and I find the changes in behaviour sane and reasonable. A quick test failed for me when the image file does not exist: $ rm image $ ./mkfs.btrfs -r . image ... not enough free space add_file_items failed unable to traverse_directory Making image is aborted. ret = -1 mkfs.btrfs: mkfs.c:1533: main: Assertion `!(ret)' failed. seems that the estimated size is not sufficient. 'du' on the directory (without the image itself) gives me 59M, the image after failed mkfs has 102M, and it's empty when I try to mount it. Using the progs .git directory (18M) as sourcedir also failed, but it worked with man/ subdirectory (94K). david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
