From owner-freebsd-questions@FreeBSD.ORG Tue Oct 16 20:14:54 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6FFD03F9 for ; Tue, 16 Oct 2012 20:14:54 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2F0968FC08 for ; Tue, 16 Oct 2012 20:14:53 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa06.fnfis.com (8.14.4/8.14.4) with ESMTP id q9GKEDEA023342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Oct 2012 15:14:52 -0500 Received: from [10.0.0.101] (10.14.152.61) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 16 Oct 2012 15:13:42 -0500 Subject: Re: MFS root filesystem and static binaries size MIME-Version: 1.0 (Apple Message framework v1283) From: Devin Teske In-Reply-To: Date: Tue, 16 Oct 2012 13:13:41 -0700 Message-ID: <79906B82-7EF3-44DD-95A1-EF1DD239E2CD@fisglobal.com> References: To: Stanislav Zaharov X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-10-16_06:2012-10-16,2012-10-16,1970-01-01 signatures=0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 20:14:54 -0000 On Oct 16, 2012, at 11:13 AM, Stanislav Zaharov wrote: > Hello, >=20 > 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= al > 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? /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 thi= s 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 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? >=20 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: >=20 > $ df -h /mnt/ >=20 > Filesystem Size Used Avail Capacity Mounted on > /dev/md0 3.9M 3.3M 534k 86% /mnt >=20 > $ 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 > ... >=20 > But: >=20 > $ du -hc /mnt/stand > ... > 3,2M total >=20 >=20 > But if we copy these files onto another UFS filesystem we really consume > the space: >=20 > $ cp -a /mnt/stand /tmp/stand >=20 > $ du -hc /tmp/stand > ... > 91M total >=20 >=20 > How is it possible and why does it matter for mfsroot? >=20 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). --=20 Cheers, Devin _____________ 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.