From owner-freebsd-questions@FreeBSD.ORG Tue Oct 16 20:24:53 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 DC25775B for ; Tue, 16 Oct 2012 20:24:53 +0000 (UTC) (envelope-from root.vagner@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9D2218FC17 for ; Tue, 16 Oct 2012 20:24:53 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id k10so13841982iea.13 for ; Tue, 16 Oct 2012 13:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WY1Jh7tje+Qhe6kL6z3v+4alNtJ6JpqdYO+hvk4GQGE=; b=FM9456bNggcgKGj5fdze9sql6075RiR+lOX0WGW7BiQ+8gw1v4/1+PVx7VuQHi0mbz a8KSz5/Qh2bDCNA/OyUUqqiBej9+BEzZAzofRcwuOJw9R4/TNagxGDB8rWp6OZp++4ee VFXu1pP1jHYDKIbVCiLQLsbjVzPQD3AROTsgXzVGU8eZUBBt9kL6TKjEv+PSemFmjWzW cpWh0YnCkCLVROHyCgtoNPLMO5SfuWSA2h31mBehjTOUXOAgD46D7nX0zQ+1x1SEXupc WIe5zedQ05j58dvl1RlPnCSrVV4Z0cgEEnrlvoXAgdxVFIexH1hwR5K6iUnkrqGewaZz WntA== MIME-Version: 1.0 Received: by 10.50.15.193 with SMTP id z1mr13358480igc.47.1350419092953; Tue, 16 Oct 2012 13:24:52 -0700 (PDT) Received: by 10.64.81.231 with HTTP; Tue, 16 Oct 2012 13:24:52 -0700 (PDT) In-Reply-To: <79906B82-7EF3-44DD-95A1-EF1DD239E2CD@fisglobal.com> References: <79906B82-7EF3-44DD-95A1-EF1DD239E2CD@fisglobal.com> Date: Wed, 17 Oct 2012 00:24:52 +0400 Message-ID: Subject: Re: MFS root filesystem and static binaries size From: Stanislav Zaharov To: freebsd-questions@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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 20:24:54 -0000 On Wed, Oct 17, 2012 at 12:13 AM, Devin Teske wrote: > > 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. > Thank you for the explanation! -- Respectfully, Stanislav Putrya System & network administrator WWW: fotostrana.ru WWW2: bsdway.ru icq: 328585847 e-mail: root.vagner@gmail.com e-mail: vagner@bsdway.ru