From owner-freebsd-questions@FreeBSD.ORG Tue Oct 16 21:40:59 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 CA0AAAAD; Tue, 16 Oct 2012 21:40:59 +0000 (UTC) (envelope-from vrwmiller@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1BF5F8FC12; Tue, 16 Oct 2012 21:40:58 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so5594225lag.13 for ; Tue, 16 Oct 2012 14:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5Qv8qR16jrf33FmeM0EPHrbFHt/gkX53B2JiVz2QMKk=; b=OMPnv5T5128D7+K9J8XrMqAl5Iij/rC8BtFkwmTVvjcikKc04pCGCYnnj6rWcBDwrE mA5XY22DPYe4MaP9XUE1tzqBFnwsMK5FgwY996Wi6jParrBXEis2cVrKAM92htBM5GNQ j7u3+Kgi6B4BhjsVBR8tgzcgzD6YnUzpLYmxahxzeKRgdbLlevvIHR4ihSZdXIKUq9D+ d2J4LXriYImMqOTFqT7gkQYzf0fQOprCWjQjOhK9YNCq3DVcl3I/3xSeyWS/3kyaTSou pFvTyOeBMMnHM00LKpTAgWTX9cbGL0vp9l9kzfequ0JYnXVXk1uA1GukbRAf8ogPa7Xp klrw== MIME-Version: 1.0 Received: by 10.112.30.136 with SMTP id s8mr3672661lbh.26.1350423657512; Tue, 16 Oct 2012 14:40:57 -0700 (PDT) Sender: vrwmiller@gmail.com Received: by 10.112.4.97 with HTTP; Tue, 16 Oct 2012 14:40:57 -0700 (PDT) In-Reply-To: <79906B82-7EF3-44DD-95A1-EF1DD239E2CD@fisglobal.com> References: <79906B82-7EF3-44DD-95A1-EF1DD239E2CD@fisglobal.com> Date: Tue, 16 Oct 2012 17:40:57 -0400 X-Google-Sender-Auth: 7ROIbZGdmV0Q_PXqGx4Pd586gOc Message-ID: Subject: Re: MFS root filesystem and static binaries size From: Rick Miller To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stanislav Zaharov , freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 21:40:59 -0000 Kudos to Devin for his explanation! On Tue, Oct 16, 2012 at 4:13 PM, Devin Teske 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