On 10/02/2017 01:47 PM, Austin S. Hemmelgarn wrote: >>> >>> What about doing it on a file instead of a device ? As sparse file, it >>> would be less expensive to enlarge then shrink. I think that who need to >>> build a filesystem with "shrink", doesn't need to create it on a real block >>> device >> >> For device, nothing different, just v3 patchset will handle it. > Agreed on this point. >> >> For file, sparse file of course. > But not on this one. Unless the image gets properly compacted, a sparse file > will only help when you're just storing the image on a filesystem.
I think that you have misunderstood my proposal... My suggestion is to create the image using a file, and after image creation compact it, and then cut it at the end. So you don't have to care about the space needing during the process (before the shrinking). Today mkfs.btrfs fails to create an image on an empty file ghigo@venice:/tmp$ mkdir test ghigo@venice:/tmp$ mkdir test/test1 ghigo@venice:/tmp$ touch test/test1/file ghigo@venice:/tmp$ mkfs.btrfs --root test disk.img btrfs-progs v4.12 See http://btrfs.wiki.kernel.org for more information. ERROR: failed to check size for disk.img: No such file or directory ghigo@venice:/tmp$ touch disk.img ghigo@venice:/tmp$ mkfs.btrfs --root test disk.img btrfs-progs v4.12 See http://btrfs.wiki.kernel.org for more information. ERROR: 'disk.img' is too small to make a usable filesystem ERROR: minimum size for each btrfs device is 41943040 you have to create a big enough ghigo@venice:/tmp$ truncate -s 10G disk.img ghigo@venice:/tmp$ mkfs.btrfs --root test disk.img btrfs-progs v4.12 See http://btrfs.wiki.kernel.org for more information. [...] BR -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
