MFS root filesystem and static binaries size

[Devin Teske]

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 actual
> occupied space is less.

The beauty of crunchgen(1).

If you use the "-i" flag to ls, you'll see the inode numbers (and subsequently 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 called), which stores a destination-path of the target, a hard link instead looks 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 file, 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 this 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 all have the same inode (whereas if you use cp, "ls -li" will instead show different inodes for every file that was copied, because again, cp(1) does not 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 install media (mfsroot) is to save space and simplify the environment. When using a crunched binary, there are no libraries to worry about for example (all the libraries are compiled-in).
-- 
Cheers,
Devin

_____________
The information contained in this message is proprietary and/or confidential. 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 aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.