Re: [PATCH 0/5] Mkfs: Rework --rootdir to a more generic behavior

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2017-09-06 14:31, Goffredo Baroncelli wrote:
> On 09/06/2017 08:02 PM, Austin S. Hemmelgarn wrote:
>> On 2017-09-06 13:48, Goffredo Baroncelli wrote:
>>> On 09/06/2017 07:16 PM, Austin S. Hemmelgarn wrote:
> [...]
>>>>> Sorry but I don't understand. If you reach the step a3; you have:
>>>>> - the final disk, and an environment fully working. So I am still inclined to think that using "mkfs.btrfs --root-dir" is more complicated in *this case*.
>>>> With the current released code (without these patches), `-r` can be used to generate a filesystem image that has zero free space.  In that case, step a3 does not give you a fully working environment,
>>>
>>> True, this doesn't *give* you a filly working environment, _but_ you perform the step a3 in a "fully working environment", an you have at hand the target disk..
>> You could just as easily be booted into a minimalistic install environment, and if you netbooted that, then it's pretty likely that you want it as small as possible, and not needing tar or btrfs-progs for the actual install will save a lot of space (multiple MB doesn't sound like much, but when you're dealing with a tiny system to begin with, it can be very significant).
> 
> Step a3 need to have access to the raw disk image build at step1; this is quite incompatible with a "minimalistic install environment"; and even if you have access it via net, in the same way you can have access to a fully working environment....
The pretty standard case for a netboot install environment for Linux is 
to have a small netboot image (usually less than 50MB) that runs 
entirely from RAM, and then downloads the system image or packages to 
install.
> 
> 
> [...]
> 
>>>>>>>
>>>>>>> where <file-to-be-created> doesn't have to exists before mkfs.btrfs, and after
>>>>>>> a) <file-to-be-created> contains the image
>>>>>>> b) <file-to-be-created> is the smallest possible size.
>>>>>>>
>>>>>>> Definitely I don't like the truncate done by the operator by hand after the mkfs.btrfs (current behavior).
>>>>>> FWIW, the current release behavior doesn't require the truncate, and properly generates the file for the filesystem.
>>>>> If you don't do truncate, you have the fully partition... Or there is something that I miss ?
>>>> The current release, without these patches, run using a non-existent file and the `-r` option, will produce a filesystem image of the exact size needed to hold everything in the directory passed to `-r`.  It doesn't require truncation unless used on a file that already exists.
>>>
>>> Of course the truncate is not needed, because you are using a sparse file. But if you use a sparse file..... it is not even needed the shrinking! Because the file will consume the same space on the disk !
> 
>> Unless you want to use the file elsewhere.  It's a pretty rare occurrence outside of testing that you generate a filesystem image and use it as-is without transferring it somewhere (usually onto an actual storage device).  Once you're talking about moving it, whether or not the file itself is sparse usually doesn't matter, especially if the file is leaving the local system by some means other than NFS or rsync.
> 
> ????
> If you don't truncate you have the full-image in any case....
How about a more concrete example.  Say you're creating a filesystem 
image on your local system for a VM you'll run on some server.  Unless 
you use rsync, NFS, or some custom software, you will probably need 
enough free space on the server to hold the entirety of the filesystem 
image including all the free space that's sparse on the local system, 
because almost any other software doesn't properly do sparse writes, and 
you'll need to call `fallocate -d` on the file on the server to make it 
sparse again.  Even working locally, there are quite a few tools that 
won't copy the file sparsely.