Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Oct 2012 17:40:57 -0400
From:      Rick Miller <vmiller@hostileadmin.com>
To:        Devin Teske <dteske@freebsd.org>
Cc:        Stanislav Zaharov <root.vagner@gmail.com>, freebsd-questions@freebsd.org
Subject:   Re: MFS root filesystem and static binaries size
Message-ID:  <CAHzLAVF15XqN6tvxvT-mEvVXY=r0-hehfRZn=M4PgmCqz3d-QA@mail.gmail.com>
In-Reply-To: <79906B82-7EF3-44DD-95A1-EF1DD239E2CD@fisglobal.com>
References:  <CAFDDX68DyV9ad9qfLWqAKmwVYOxYwBvdEKmFWU+nMpEurAvuig@mail.gmail.com> <79906B82-7EF3-44DD-95A1-EF1DD239E2CD@fisglobal.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Kudos to Devin for his explanation!

On Tue, Oct 16, 2012 at 4:13 PM, Devin Teske <devin.teske@fisglobal.com> wr=
ote:
>
> On Oct 16, 2012, at 11:13 AM, Stanislav Zaharov wrote:
>
>> Hello,
>>
>> I have a question regarding the mfsroot file system organization on
>> installation cd.
>> How is it possible that we have bigger binary files in ls list while act=
ual
>> occupied space is less.
>
> The beauty of crunchgen(1).
>
> If you use the "-i" flag to ls, you'll see the inode numbers (and subsequ=
ently notice that a great-many inodes are identical).
>
> When two files have the same inode, they are "hard links" to each other. =
Unlike a "soft link" (or "symbolic link" as they are more appropriately cal=
led), which stores a destination-path of the target, a hard link instead lo=
oks and acts no different than the original in every way.
>
> So, I can hear you asking, if all these binaries are linked to the same f=
ile, what file is that?
>
> /stand/boot_crunch
>
> This is a "crunched" binary (produced by crunchgen(1)).
>
> Here's the configuration file that is fed to crunchgen(1) that produces t=
his binary:
>
> http://svn.freebsd.org/base/stable/9/release/i386/boot_crunch.conf
>
> Quite simply, crunchgen(1) takes a list of programs (progs) and libraries=
 (libs) and produces a "crunched" binary.
>
> You then create links (hard or soft) to the crunched binary. The crunched=
 binary knows by argv[0] which main() subroutine to invoke.
>
> This ultimately allows things to stay nice and tight (storage space-wise)=
.
>
>
>
>> But when we try to copy these files on similar
>> filesystem using cp or dd the actual used space is bigger?
>>
>
> cp(1) doesn't track hard-links.
>
> tar(1) does.
>
> If you want to copy /stand out of the mfsroot, you can do this:
>
> mkdir /stand2
> tar cf - /stand | tar xf - -C /stand2
>
> A corresponding "ls -li /stand2" should show that the majority of files a=
ll have the same inode (whereas if you use cp, "ls -li" will instead show d=
ifferent inodes for every file that was copied, because again, cp(1) does n=
ot support retention of hard-links).
>
>
>
>
>> For example when we mount mfsroot image we get:
>>
>> $ df -h /mnt/
>>
>> Filesystem    Size    Used   Avail Capacity  Mounted on
>> /dev/md0      3.9M    3.3M    534k    86%    /mnt
>>
>> $ ls -lhs /mnt/stand
>> ...
>>  766 -r-xr-xr-x  30 root  wheel     3M 10 apr  2012 dhclient
>>  766 -r-xr-xr-x  30 root  wheel     3M 10 apr  2012 cpio
>>  766 -r-xr-xr-x  30 root  wheel     3M 10 apr  2012 camcontrol
>>  766 -r-xr-xr-x  30 root  wheel     3M 10 apr  2012 boot_crunch
>> ...
>>
>> But:
>>
>> $ du -hc /mnt/stand
>> ...
>> 3,2M    total
>>
>>
>> But if we copy these files onto another UFS filesystem we really consume
>> the space:
>>
>> $ cp -a /mnt/stand /tmp/stand
>>
>> $ du -hc /tmp/stand
>> ...
>> 91M    total
>>
>>
>> How is it possible and why does it matter for mfsroot?
>>
>
> The reason crunchgen(1) is used to create /stand/boot_crunch for the inst=
all media (mfsroot) is to save space and simplify the environment. When usi=
ng a crunched binary, there are no libraries to worry about for example (al=
l the libraries are compiled-in).
> --
> Cheers,
> Devin
>
> _____________
> The information contained in this message is proprietary and/or confident=
ial. If you are not the intended recipient, please: (i) delete the message =
and all copies; (ii) do not disclose, distribute or use the message in any =
manner; and (iii) notify the sender immediately. In addition, please be awa=
re that any message addressed to our domain is subject to archiving and rev=
iew by persons other than the intended recipient. Thank you.
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.o=
rg"



--=20
Take care
Rick Miller



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?CAHzLAVF15XqN6tvxvT-mEvVXY=r0-hehfRZn=M4PgmCqz3d-QA>