Giuseppe Scrivano wrote: > Hi Pádraig, > > thanks for the comments. > > Pádraig Brady <p...@draigbrady.com> writes: > >> # 300MB seems to be the minimum size for a btrfs with default >> parameters. > > Actually, it seems the minimum space required is 256MB. Using a 255MB > image I get: "device btrfs.img is too small (must be at least 256 MB)"
I tried that with my version of btrfs but still got the "too small" error. I probably did something silly. >> # FIXME: use `truncate --allocate` when it becomes available, which >> # may allow unmarking this as an expensive test. > > Are you sure that this feature will make the test less expensive? Still > the test files must be written there, so in the best case (considering > the fallocate done in 0s) only the dd cost will be saved but still it > looks like an expensive test. Well with fallocate() I expect only the file system meta data to be modified, thus obviating moving any zeros around. But you're right that the mkfs will probably have to write lots of data. > In the version I attached, I am using a sparse file (truncate --size) > and it seems to work fine. Is it correct or am I missing something? Nope, good idea! I guess the mkfs writes all the blocks anyway as mentioned above, but this is now done only once. > I haven't looked yet but probably there are other tests that can take > advantage of sparse files instead of using "dd". > > I am also considering the Jim's note doing the umount in the cleanup_ I noticed that also but got distracted :p > diff --git a/tests/cp/file-clone b/tests/cp/file-clone > + > +require_root_ > +require_sparse_support_ > +#expensive_ That comment is just for testing I presume? Note you can run a single expensive test like: (cd tests && make check TESTS=cp/file-clone VERBOSE=yes RUN_EXPENSIVE_TESTS=yes) cheers, Pádraig. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
