[arch-releng] [PATCH 1/1] allow to grow devices

[Christian Hesse]

Gerardo Exequiel Pozzi <vmlinuz386 at yahoo.com.ar> on Sun, 2013/09/01 19:36:
> On 09/01/2013 01:34 PM, Christian Hesse wrote:
> > Gerardo Exequiel Pozzi <vmlinuz386 at yahoo.com.ar> on Fri, 2013/08/30 19:17:
> >> On 08/30/2013 06:36 PM, Christian Hesse wrote:
> >>> Gerardo Exequiel Pozzi <vmlinuz386 at yahoo.com.ar> on Fri, 2013/08/30
> >>> 13:01:
> >>>> On 08/30/2013 06:12 AM, Christian Hesse wrote:
> >>>>> Just thinking about how to integrate the userspace tools and handling
> >>>>> for this. I would like to add a new hook that adds the binary files
> >>>>> (resize2fs, xfs_growfs, btrfs), so anybody can decide whether or not
> >>>>> to include. But where do we call this?
> >>>>
> >>>> I did not see any real usage of this "extension" inside official image.
> >>>> If you are building a custom image build, why not just create a big
> >>>> filesystem from the start?
> >>>
> >>> Because bigger filesystem has more metadata. Image size would increase
> >>> for a use case I need only very seldom.
> >>> I perfer to add some lines of code, having the possibility to grow
> >>> device and filesystem when needed.
> >>>
> >>
> >> True, but this can be done from another perspective, just create a big
> >> file for filesystem, but use few blocks, since squashfs supports sparse
> >> files.
> >>
> >> To do this in the most trivial way is just adding one line to mkarchiso.
> >> Let says: truncate -s 16G ${_fs_img} after "mkfs". (or even better!
> >> truncate -s 2T ${_fs_img} :D)
> > 
> > I should have thought of that before... Great idea!
> 
> Good :)
> 
> > Any chance to get that upstream? I do not want it enabled by default, but
> > with a parameter.
> 
> Its safe to be enabled by default, without adding additional parameter,
> but not in fixed size, I guess at most as double of filesystem size
> should be sufficient.

I will reply with a patch.

> If another parameter should be adeed can be in aitab or via an argument
> in mkarchiso.

Will think about that.
Do we want code to handle the fs growing? This could be done after chroot as
fine.

> >> There is only one downside if cowspace should be stored on filesystems
> >> that does not support sparse files like FAT cowspace_size= is much more
> >> important to be specified now.
> > 
> > I do not have fat32 for that here, so no problem.
> > 
> >> This avoid at all this complex logic, what do you think?
> > 
> > As said before... Great idea. ;) Will give it a test now.
> > 
> 
> Nice :)

Works just perfectly. ;)
-- 
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Chris           get my mail address:    */=0;b=c[a++];)
putchar(b-1/(/*               gcc -o sig sig.c && ./sig    */b/42*2-3)*42);}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-releng/attachments/20130902/42a87f1e/attachment.asc>