Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Oct 2012 13:13:41 -0700
From:      Devin Teske <>
To:        Stanislav Zaharov <>
Subject:   Re: MFS root filesystem and static binaries size
Message-ID:  <>
In-Reply-To: <>
References:  <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

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

The beauty of crunchgen(1).

If you use the "-i" flag to ls, you'll see the inode numbers (and subsequen=
tly notice that a great-many inodes are identical).

When two files have the same inode, they are "hard links" to each other. Un=
like a "soft link" (or "symbolic link" as they are more appropriately calle=
d), which stores a destination-path of the target, a hard link instead look=
s 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 fil=
e, what file is that?


This is a "crunched" binary (produced by crunchgen(1)).

Here's the configuration file that is fed to crunchgen(1) that produces thi=
s binary:

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 b=
inary 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 dif=
ferent 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 instal=
l 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).

The information contained in this message is proprietary and/or confidentia=
l. If you are not the intended recipient, please: (i) delete the message an=
d all copies; (ii) do not disclose, distribute or use the message in any ma=
nner; and (iii) notify the sender immediately. In addition, please be aware=
 that any message addressed to our domain is subject to archiving and revie=
w by persons other than the intended recipient. Thank you.

Want to link to this message? Use this URL: <>