From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f195.google.com ([209.85.223.195]:37743 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751328AbdIFSqN (ORCPT ); Wed, 6 Sep 2017 14:46:13 -0400 Received: by mail-io0-f195.google.com with SMTP id p63so44038ioe.4 for ; Wed, 06 Sep 2017 11:46:12 -0700 (PDT) Subject: Re: [PATCH 0/5] Mkfs: Rework --rootdir to a more generic behavior To: kreijack@inwind.it, linux-btrfs@vger.kernel.org Cc: dsterba@suse.cz, Qu Wenruo References: <20170904064110.25951-1-quwenruo.btrfs@gmx.com> <20170904180856.GG31874@twin.jikos.cz> <50438174-ffce-031c-1148-f2e61bf35f68@inwind.it> <8aa1c1e2-e938-f011-7306-8480e1f06c49@gmail.com> <66d243a6-e3e0-bccc-1f29-008189fb612d@inwind.it> <03325479-bb84-2d07-f4dc-e22c81da92d8@inwind.it> From: "Austin S. Hemmelgarn" Message-ID: <3663191e-7358-0ba2-1575-d0eda3d97fff@gmail.com> Date: Wed, 6 Sep 2017 14:46:09 -0400 MIME-Version: 1.0 In-Reply-To: <03325479-bb84-2d07-f4dc-e22c81da92d8@inwind.it> Content-Type: text/plain; charset=utf-8; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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 doesn't have to exists before mkfs.btrfs, and after >>>>>>> a) contains the image >>>>>>> b) 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.