Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:11186 gnu.misc.discuss:15397 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!ihnp4.ucsd.edu!swrinde!emory!cherry.atlanta.com!nntp.mindspring.com!usenet From: rsanders@mindspring.com (Robert Sanders) Newsgroups: comp.os.386bsd.questions,gnu.misc.discuss Subject: Re: Taylor UUCP on FreeBSD??? Date: 23 Jun 1994 04:57:20 GMT Organization: MindSpring Enterprises, Inc. Lines: 83 Message-ID: <RSANDERS.94Jun23005720@hrothgar.mindspring.com> References: <1994Jun13.040754.17764@kosman.uucp> <RS ANDERS.94Jun21155032@hrothgar.mindspring.com> <2u7tcb$6mr@pdq.coe.montana.edu> <RSANDERS.94Jun22110639@hrothgar.mindspring.com> <1994Jun22.184617.10333@cm.cf.ac.uk> NNTP-Posting-Host: msdem5.mindspring.com In-reply-to: paul@myrddin.isl.cf.ac.uk's message of Wed, 22 Jun 1994 18:46:16 +0000 In article <1994Jun22.184617.10333@cm.cf.ac.uk> paul@myrddin.isl.cf.ac.uk (Paul) writes: In article <RSANDERS.94Jun22110639@hrothgar.mindspring.com>, Robert Sanders <rsanders@mindspring.com> wrote: >Linux's shared libc and libm add up to about 280K (they look bigger, >but they contain holes). I really couldn't tell you for sure how much ^^^^^^^^^^^^ Uhh, I don't entirely follow the relevance of that. Well, on a Unix filesystem, if a file has a long run of zeroes that touch both boundaries of one or mor blocks, it may be possible to represent that run of zeroes without actually allocating a block. In the blocklist of the inode, a magic block number (usually 0) is put in place of an actual block number; when reading a file, if the kernel comes across any of these "holes" it simply returns a block of all zeroes as the data content without actually reading from disk. So, while the files look this large: -rwxr-xr-x 1 root root 623620 Jun 22 10:54 /lib/libc.so.4.5.26 -rwxr-xr-x 1 root root 107524 Apr 4 17:31 /lib/libm.so.4.5.26 du shows they actually only use this much space: 275 /lib/libc.so.4.5.26 15 /lib/libm.so.4.5.26 You may know all that; others may not. What I was doing was trying to prevent anyone from saying "no, they're much bigger than that." In any case, that's hardly the entire /usr/lib now is it? Our libc.so is 398K and libm is 56K. The entire /usr/lib is over 3Mb and that's without the profiled libraries and no old shared libraries. All you need on the root partition is the shared libraries necessary to run the binaries on the root partition. I have libc.so and libm.so and no other shared libraries are used by any of my /bin and /sbin binaries. > 5) ld.so doesn't NEED to be in /root, and there is less likely for > something bad to get hosed up when doing updates. The more dependant > you are on particular tools, the more likely one of them is to break. > Upon bootup there are 2 CRITICAL binaries. 'init' and 'sh' for > safety reasons should be linked static IMHO. > >This is a different argument from whether or not the shared libraries >should be accessible at boottime and used by binaries on the root >partition. I have no argument with this. Well, not really. The only reason that there are binaries on root in the first place is to use them for booting and when down single user performing repairs. Given those two criteria most of the binaries on / are pretty important. If you ever have a crash where the shared libs on / get hosed you'll realise how much of a pain this can be because the tools you need to repair the system won't run. I've heard this argument before and I don't think it's that overwhelming (although it's certainly not invalid). If I have a problem so catastrophic I have to go into single-user mode, I usually pull out a bootable root disk and do my repairs with a known good system. Just as a data point, in almost two years of use, my Linux system has never failed to boot because the shared libraries were corrupted. Well, in Nate's defence there was a :-) after his statement. In any case, there are some good reasons why we'd have this attitude anyway. [...] 2) It's very big and size is at a premium on / Actually, as Bruce Evans pointed out, using shared libraries saves you a lot of space on / :-). However, I agree that it would be nice to have a lean, swift /bin/sh for scripts. I almost installed ash a while back, but after seeing it fail on 3 or 4 scripts, I decided bash was fast enough for me. 3) Fixing ash is the more "correct" solution. How? Point #3 is begging the question, your honor. -- Robert