[arch-releng] [PATCH 1/1] double file size with sparse blocks

[Christian Hesse]

Gerardo Exequiel Pozzi <vmlinuz386 at yahoo.com.ar> on Wed, 2014/03/19 22:21:
> On 01/11/2014 08:35 AM, Christian Hesse wrote:
> > Gerardo Exequiel Pozzi <vmlinuz386 at yahoo.com.ar> on Fri, 2014/01/10 23:53:
> >> On 01/10/2014 11:47 PM, Gerardo Exequiel Pozzi wrote:
> >>> On 01/09/2014 05:49 AM, Christian Hesse wrote:
> >>>> Christian Hesse <list at eworm.de> on Mon, 2013/09/02 10:03:
> >>>>> From: Christian Hesse <mail at eworm.de>
> >>>>>
> >>>>> This allows to grow the filesystem after system boot up. We have no
> >>>>> additional cost as squashfs handles sparse files.
> >>>>> ---
> >>>>>  archiso/mkarchiso | 2 ++
> >>>>>  1 file changed, 2 insertions(+)
> >>>>>
> >>>>> diff --git a/archiso/mkarchiso b/archiso/mkarchiso
> >>>>> index 8f9ed42..563f624 100755
> >>>>> --- a/archiso/mkarchiso
> >>>>> +++ b/archiso/mkarchiso
> >>>>> @@ -364,6 +364,8 @@ _mkfs () {
> >>>>>      cp -aT "${_fs_src}/" "${work_dir}/mnt/${_src}/"
> >>>>>      _msg_info "Done!"
> >>>>>      _umount_fs "${work_dir}/mnt/${_src}"
> >>>>> +    # double size with sparse blocks, will allow to grow the
> >>>>> filesystem
> >>>>> +    truncate -s$((_fs_size*2))M "${_fs_img}"
> >>>>>  }
> >>>>>  
> >>>>>  command_checksum () {
> >>>>
> >>>> Currently I am maintaining this in a local package for myself. Any
> >>>> chance to get this merged upstream?
> >>>>
> >>>
> >>> No. This is a special case. If root-image.fs.sfs is copied to a
> >>> filesystems that does not support sparse files (FAT commonly for
> >>> USB-keys), this is waste of free space.
> >>>
> >>
> >> brb, ignore me!! truncate is on root-image.fs not root-images.fs.sfs :P
> >>
> >> Yes, this can be safe by default and can be included for next release :)
> > 
> > Great, thanks!
> > 
> 
> I am still not changing this because, I am thinking in a different way
> to do this, in a more "systemd-friendly-way" (because currently I need
> to mount the squashfs, then fetch the size in blocks of the file inside
> it...).
> This is, for all cases, create a fixed size of the filesystem, (i.e 4G
> or 8G), the overhead is minimal, really :)
> 
> 
> $ truncate -s 1G coco.fs
> $ mkfs.ext4 -q -O ^has_journal -E lazy_itable_init=0 -m 0 -F coco.fs
> $ du -h coco.fs
> 408K    coco.fs
> $ truncate -s 16G pepe.fs
> $ mkfs.ext4 -q -O ^has_journal -E lazy_itable_init=0 -m 0 -F pepe.fs
> $ du -h pepe.fs
> 4.3M    pepe.fs

Not sure if I got you right... With this solution you want the filesystem to
always fill the whole file? Where is the size specified?

I wonder why you need the filesystem size in a systemd setup. What is it good
for?

You could create a filesystem that fits the needed size, truncate the
file and have a fixed size nevertheless.

$ _fs_size=1024
$ truncate -s ${_fs_size}M coco.fs
$ mkfs.ext4 -q -O ^has_journal -E lazy_itable_init=0 -m 0 -F coco.fs
$ du -h coco.fs
408K    coco.fs
$ truncate -s 16G coco.fs
$ du -h coco.fs
408K    coco.fs

And optionally later in live environment:

$ resize2fs coco.fs
$ du -h coco.fs
4.3M    coco.fs
-- 
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/20140320/c81f29f1/attachment.asc>