What does /usr mean anyway?
Lawrence DąOliveiro
/usr/sbin? Why is there a /usr/share but no /share? /usr/local but not
/local? If something runs from /usr/bin or /usr/sbin instead of /bin or
/sbin, why does its configuration live in /etc and not /usr/etc?
Floyd L. Davidson
History. Simple as that.
Originally the AT&T UNIX, from whence all this comes, was on a
PDP-7 computer. There were no huge disks, as this was
1969-1973.
There was the root file system, which contained everything
necessary to boot the system. And on that fs would be such
directories as /bin for binaries, and /lib for libraries. That
was the basic system. If someone wanted to do admin work they
mounted /etc, where all the odd things needed to do
administration were located. And if the system was to be turned
loose to users, the /usr file system was mounted.
The /usr filesystem had such directories as /usr/home, where all
the various users had their home directories, and /usr/lib and
/usr/bin where libraries and programs for users, but unnecessary
for booting or maintenance, were located.
Both the /usr/share and /usr/local came much later. /usr/local
began to make sense when there was a "UNIX distribution" and
that was different from locally maintained software. The idea
of a /usr/share directory of course came with networking (RFS
and NFS), and is meant to hold data shared via remote mounted
file systems across multiple hosts.
Likewise the distinction between bin and sbin directories is
that normal users need not have access to sbin, which is only
needed by system administators (this being long after /etc
became permanently mounted, and part of the concept with sbin is
to get binaries out of /etc).
For anyone who got into UNIX as late as V7 or maybe even up into
the SysVR2 era, it was all fairly simple and relatively obvious.
But BSD systems and SysV were already seriously different by
that time, and things began to get twisted up in ways that are
not so easy to see. SysVR4 attempted to join them again, but
probably succeeded only in more confusion as since then there
have been odd mixes of concepts from both.
--
FloydL. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) fl...@barrow.com
Robert Heller
In a message on Sun, 24 Oct 2004 16:51:42 -0800, wrote :
FLD> Lawrence DąOliveiro <l...@geek-central.gen.new_zealand> wrote:
FLD> >Why is there a /lib versus /usr/lib? /bin versus /usr/bin? /sbin versus
FLD> >/usr/sbin? Why is there a /usr/share but no /share? /usr/local but not
FLD> >/local? If something runs from /usr/bin or /usr/sbin instead of /bin or
FLD> >/sbin, why does its configuration live in /etc and not /usr/etc?
FLD>
FLD> History. Simple as that.
FLD>
FLD> Originally the AT&T UNIX, from whence all this comes, was on a
FLD> PDP-7 computer. There were no huge disks, as this was
FLD> 1969-1973.
FLD>
FLD> There was the root file system, which contained everything
FLD> necessary to boot the system. And on that fs would be such
FLD> directories as /bin for binaries, and /lib for libraries. That
FLD> was the basic system. If someone wanted to do admin work they
FLD> mounted /etc, where all the odd things needed to do
FLD> administration were located. And if the system was to be turned
FLD> loose to users, the /usr file system was mounted.
FLD>
FLD> The /usr filesystem had such directories as /usr/home, where all
FLD> the various users had their home directories, and /usr/lib and
FLD> /usr/bin where libraries and programs for users, but unnecessary
FLD> for booting or maintenance, were located.
FLD>
FLD> Both the /usr/share and /usr/local came much later. /usr/local
FLD> began to make sense when there was a "UNIX distribution" and
FLD> that was different from locally maintained software. The idea
FLD> of a /usr/share directory of course came with networking (RFS
FLD> and NFS), and is meant to hold data shared via remote mounted
FLD> file systems across multiple hosts.
FLD>
FLD> Likewise the distinction between bin and sbin directories is
FLD> that normal users need not have access to sbin, which is only
FLD> needed by system administators (this being long after /etc
FLD> became permanently mounted, and part of the concept with sbin is
FLD> to get binaries out of /etc).
FLD>
FLD> For anyone who got into UNIX as late as V7 or maybe even up into
FLD> the SysVR2 era, it was all fairly simple and relatively obvious.
FLD> But BSD systems and SysV were already seriously different by
FLD> that time, and things began to get twisted up in ways that are
FLD> not so easy to see. SysVR4 attempted to join them again, but
FLD> probably succeeded only in more confusion as since then there
FLD> have been odd mixes of concepts from both.
Note that *some* of us still use a separate file system for /usr, /var,
and /home (and sometimes /var/spool). There are a number of
administrative reasons for doing this. Backups and crash recovery for
starters. In *theory* it is possible to get a system running in single
user mode with only 'core' (root) file system mounted: /boot, /bin,
/sbin, /etc, /dev, and /sbin -- this set of directories contain enough
utilities to do whatever is needed to repair any problems. I did once
manage to make a backup of my root file system to a Zip drive and was
able to boot the system with my Zip drive as the root file system and
repair a problem with my main disk.
Since the core set of directories is relatively 'static', a hard crash
will likely never leave anything around to bother fsck and being a
relatively small file system, a fsck of the root system is fast and
unlikely to ever have problems (unless the disk seriously crashes).
This means that short of a totally catastrophic disk failure, the system
will boot up enough to repair almost any other problem.
FLD>
FLD> --
FLD> FloydL. Davidson <http://web.newsguy.com/floyd_davidson>
FLD> Ukpeagvik (Barrow, Alaska) fl...@barrow.com
FLD>
\/
Robert Heller ||InterNet: hel...@cs.umass.edu
http://vis-www.cs.umass.edu/~heller || hel...@deepsoft.com
http://www.deepsoft.com /\FidoNet: 1:321/153
Nick Landsberg
> Lawrence D¹Oliveiro <l...@geek-central.gen.new_zealand> wrote:
>
>>Why is there a /lib versus /usr/lib? /bin versus /usr/bin? /sbin versus
>>/usr/sbin? Why is there a /usr/share but no /share? /usr/local but not
>>/local? If something runs from /usr/bin or /usr/sbin instead of /bin or
>>/sbin, why does its configuration live in /etc and not /usr/etc?
>
>
> History. Simple as that.
>
> Originally the AT&T UNIX, from whence all this comes, was on a
> PDP-7 computer. There were no huge disks, as this was
> 1969-1973.
>
> There was the root file system, which contained everything
> necessary to boot the system. And on that fs would be such
> directories as /bin for binaries, and /lib for libraries. That
> was the basic system. If someone wanted to do admin work they
> mounted /etc, where all the odd things needed to do
> administration were located. And if the system was to be turned
> loose to users, the /usr file system was mounted.
>
> The /usr filesystem had such directories as /usr/home, where all
> the various users had their home directories, and /usr/lib and
> /usr/bin where libraries and programs for users, but unnecessary
> for booting or maintenance, were located.
Minor nit, Floyd. In ancient history, /usr/home didn't exist and
users were directly under /usr. The first tape I got of Unix
(on a PDP-11) had directories for /usr/ken and /usr/dmr
(whose directories they were is left as an exercise for the
reader, but I will say that to compile the kernel, I had
to step into both of them and type in the appropriate
compilation command ... pre "make").
>
> Both the /usr/share and /usr/local came much later. /usr/local
> began to make sense when there was a "UNIX distribution" and
> that was different from locally maintained software. The idea
> of a /usr/share directory of course came with networking (RFS
> and NFS), and is meant to hold data shared via remote mounted
> file systems across multiple hosts.
>
> Likewise the distinction between bin and sbin directories is
> that normal users need not have access to sbin, which is only
> needed by system administators (this being long after /etc
> became permanently mounted, and part of the concept with sbin is
> to get binaries out of /etc).
>
> For anyone who got into UNIX as late as V7 or maybe even up into
> the SysVR2 era, it was all fairly simple and relatively obvious.
> But BSD systems and SysV were already seriously different by
> that time, and things began to get twisted up in ways that are
> not so easy to see. SysVR4 attempted to join them again, but
> probably succeeded only in more confusion as since then there
> have been odd mixes of concepts from both.
>
Amen to what you said about the mixed concepts. You almost have
to switch from a SysV mindset to a BSD mindset to operate
properly in them. Still a lot better than the alternative.
NPL
--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
David L. Johnson
> History. Simple as that.
All in all, a very good explanation. It would have been simple enough to
tell the OP that he could make whatever directories he wanted, but you
provided story behind how the standard names came about, which is what was
needed. I never knew about /etc being only mounted for admins, but then I
came into this several years after all this was thrashed out.
--
David L. Johnson
__o | If all economists were laid end to end, they would not reach a
_`\(,_ | conclusion. -- George Bernard Shaw
(_)/ (_) |
Lawrence DąOliveiro
Robert Heller <hel...@deepsoft.com> wrote:
>Note that *some* of us still use a separate file system for /usr, /var,
>and /home (and sometimes /var/spool). There are a number of
>administrative reasons for doing this. Backups and crash recovery for
>starters. In *theory* it is possible to get a system running in single
>user mode with only 'core' (root) file system mounted: /boot, /bin,
>/sbin, /etc, /dev, and /sbin -- this set of directories contain enough
>utilities to do whatever is needed to repair any problems.
"You said /sbin twice."
"I like /sbin."
(with apologies to Mel Brooks.)
These days it's simpler to put the whole OS installation into a single
partition, I think. Then the /usr distinction becomes moot.
Lawrence DąOliveiro
fl...@barrow.com (Floyd L. Davidson) gave a useful explanation:
>The /usr filesystem had such directories as /usr/home, where all
>the various users had their home directories, and /usr/lib and
>/usr/bin where libraries and programs for users, but unnecessary
>for booting or maintenance, were located.
I must admit, I've been using ldd on a few binaries in /bin and /sbin on
my SuSE 9.1 install, and I have yet to find one that depends on anything
in /usr/lib.
>The idea
>of a /usr/share directory of course came with networking (RFS
>and NFS), and is meant to hold data shared via remote mounted
>file systems across multiple hosts.
Except that on a current Linux distro it is used for nothing like that.
It seems to be a place for documentation (including man pages), and also
for read-only data, graphics, fonts etc.
>Likewise the distinction between bin and sbin directories is
>that normal users need not have access to sbin, which is only
>needed by system administators...
Which means that /usr/sbin is kind of a contradiction in terms, isn't it?
>... (this being long after /etc
>became permanently mounted, and part of the concept with sbin is
>to get binaries out of /etc).
So "/etc" started out as kind of a miscellaneous holding place, and
ended up becoming the holder for configuration files?
Who introduced /opt? I suppose that was a Sun thing?
Floyd L. Davidson
> fl...@barrow.com (Floyd L. Davidson) gave a useful explanation:
>
>>of a /usr/share directory of course came with networking (RFS
>>and NFS), and is meant to hold data shared via remote mounted
>>file systems across multiple hosts.
>
>Except that on a current Linux distro it is used for nothing like that.
No, it is *exactly* like that!
>It seems to be a place for documentation (including man pages), and also
>for read-only data, graphics, fonts etc.
All of which are independant of the host architecture! They can be
shared across a network mounted filesystem to any host.
>>Likewise the distinction between bin and sbin directories is
>>that normal users need not have access to sbin, which is only
>>needed by system administators...
>
>Which means that /usr/sbin is kind of a contradiction in terms, isn't it?
Not really. The root file system is just tools to boot the
system and do repair maintenance if necessary. The tools in
/usr/sbin are for systems administration of whatever kind needs
to be done only when the system as a whole is up and running,
but are still tools that normal users would not need.
>Who introduced /opt? I suppose that was a Sun thing?
Yes, rumor has it that Sun did that. I always thought it
came from Microsoft though... even if a little indirectly. ;-)
Floyd L. Davidson
>In article <e15db$417c6020$cb248f0$62...@nf1.news-service-com>,
> Robert Heller <hel...@deepsoft.com> wrote:
>
>>Note that *some* of us still use a separate file system for /usr, /var,
>>and /home (and sometimes /var/spool). There are a number of
>>administrative reasons for doing this. Backups and crash recovery for
>>starters. In *theory* it is possible to get a system running in single
>>user mode with only 'core' (root) file system mounted: /boot, /bin,
>>/sbin, /etc, /dev, and /sbin -- this set of directories contain enough
>>utilities to do whatever is needed to repair any problems.
...
>These days it's simpler to put the whole OS installation into a single
>partition, I think. Then the /usr distinction becomes moot.
That may be simpler, but it is *not* a good idea. Robert is *exactly*
correct. In addition to the above, it is not uncommon to have /usr
mounted read only, which provides some additional protection.
John Hasler
> In addition to the above, it is not uncommon to have /usr mounted read
> only, which provides some additional protection.
Some protection is also provided by mounting everything not mounted
read-only noexec (not practical on a development machine, of course).
--
John Hasler
jo...@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
Markku Kolkka
> I must admit, I've been using ldd on a few binaries in /bin and /sbin
> on my SuSE 9.1 install, and I have yet to find one that depends on
> anything in /usr/lib.
Good. The system would be broken if something in /bin or /sbin required
anything from /usr.
> Which means that /usr/sbin is kind of a contradiction in terms, isn't
> it?
No, there are plenty of system administration programs that aren't
needed in boot or single user mode.
You really should read the FHS: http://www.pathname.com/fhs/
--
Markku Kolkka
markku...@iki.fi
Menno Duursma
> fl...@barrow.com (Floyd L. Davidson) gave a useful explanation:
>>Likewise the distinction between bin and sbin directories is
>>that normal users need not have access to sbin, which is only
>>needed by system administators...
>
> Which means that /usr/sbin is kind of a contradiction in terms, isn't it?
Well, not if "usr" is actually an abbreviation of: Unix System Resource
http://lists.freebsd.org/pipermail/freebsd-chat/2003-December/001713.html
Otherwise, i see your point.
But who knows maybe "sbin" stands for:
Shoaly BOFH Intermittent Nuance
--
-Menno.
David L. Johnson
> But who knows maybe "sbin" stands for:
I started noticing /sbin/ in distributions when shared libraries started
appearing. Yes, there was a time when most executables were statically
linked. I always thought that /sbin/ held binary executables that had to
be statically linked, hence the "s". But, in checking out my own /sbin/
directory, I see that is at least no longer the case, and darn few
programs are static --- meaning that darn near everyghing depends on a
well-functioning system. Scary.
--
David L. Johnson
__o | Arguing with an engineer is like mud wrestling with a pig... You
_`\(,_ | soon find out the pig likes it!
(_)/ (_) |
name
<snip excellent explanation>
Would it be fair to say that the standard three tiers *now* present separate
levels of 1) System files, 2) Distro files, 3) Custom rolled stuff?
Ummm... that's 1) /, 2) /usr, 3) /usr/local.
Dunno if this makes sense to anyone else, but I install nothing but binaries
from the distro under /usr, and nothing but tarball builds under /usr/local.
Keeps things tidy...
--
Email is wtallman at olypen dot com
Lawrence DąOliveiro
fl...@barrow.com (Floyd L. Davidson) wrote:
>Lawrence DąOliveiro <l...@geek-central.gen.new_zealand> wrote:
>>In article <e15db$417c6020$cb248f0$62...@nf1.news-service-com>,
>>
>>These days it's simpler to put the whole OS installation into a single
>>partition, I think. Then the /usr distinction becomes moot.
>
>That may be simpler, but it is *not* a good idea. Robert is *exactly*
>correct. In addition to the above, it is not uncommon to have /usr
>mounted read only, which provides some additional protection.
Protection against what? The number one danger you have to worry about,
by about an order of magnitude, is a hard disk crash. When the disk
goes, all the partitions go, so partitioning doesn't help you any there.
Lawrence DąOliveiro
fl...@barrow.com (Floyd L. Davidson) wrote:
>Lawrence DąOliveiro <l...@geek-central.gen.new_zealand> wrote:
>> fl...@barrow.com (Floyd L. Davidson) gave a useful explanation:
>>
>>>The idea
>>>of a /usr/share directory of course came with networking (RFS
>>>and NFS), and is meant to hold data shared via remote mounted
>>>file systems across multiple hosts.
>>
>>Except that on a current Linux distro it is used for nothing like that.
>
>No, it is *exactly* like that!
>
>>It seems to be a place for documentation (including man pages), and also
>>for read-only data, graphics, fonts etc.
>
>All of which are independant of the host architecture! They can be
>shared across a network mounted filesystem to any host.
Which means that /usr/lib/perl5 should also be in /usr/share, shouldn't
it? But it's not.
One LAN cluster I'm responsible for is a mixture of two platforms:
Linux-Intel and Tru64-Alpha. Each platform shares a common /usr/local
containing platform-specific binaries. In addition, I created a
/usr/local/common area which contains non-platform-specific data.
Peter T. Breuer
> Protection against what? The number one danger you have to worry about,
> by about an order of magnitude, is a hard disk crash. When the disk
> goes, all the partitions go, so partitioning doesn't help you any there.
When the hard disk crashes it is normally because of a bad voltage spike
or similar. When that happens, about one in five hundred times (well,
my rough guess given the number of time I've seen it - about ten) it
seems the heads land badly no matter the manufacturers say that is
impossible and they should float. When they do that they tear up the
disk. Partitioned disks allow you to boot, since the damage is unlikely
to be on the (small) root partition. And they allow you to recover,
since you can "wall off" the damaged area.
Such damage is normally recognizable becuase of the pattern. There will
be a large area of damaged sectors, and then smaller areas each approx 8MB
away from the last (or whatever pases for the size of a cylinder on
that disk), until the damage fades out about 50-100MB away.
Peter
Menno Duursma
> On Mon, 25 Oct 2004 16:30:32 +0000, Menno Duursma wrote:
>
>> But who knows maybe "sbin" stands for:
>
> I started noticing /sbin/ in distributions when shared libraries started
> appearing. Yes, there was a time when most executables were statically
> linked. I always thought that /sbin/ held binary executables that had to
> be statically linked, hence the "s".
That sounds way more plausible then what i came up with :-).
> But, in checking out my own /sbin/ directory, I see that is at least no
> longer the case, and darn few programs are static --- meaning that darn
> near everyghing depends on a well-functioning system. Scary.
Well, i noticed that too. That is when i started to copy the busybox
system used for install: /mnt/cdrom/isolinux/initrd.img - to /boot .
And some machines i admin have "sash" in /bin or ~/bin also.
(IIRC /sbin on FreeBSD was static - last i looked at it...)
--
-Menno.
Peter T. Breuer
I have a statically compiled zsh. As well as statically compiled copies
of ln (important for when the soft link to libc.so blows :), cp, mv
and so on.
Peter
Robert Heller
In a message on Tue, 26 Oct 2004 18:43:53 +1300, wrote :
LD> In article <87mzybm...@barrow.com>,
LD> fl...@barrow.com (Floyd L. Davidson) wrote:
LD>
LD> >Lawrence DąOliveiro <l...@geek-central.gen.new_zealand> wrote:
LD> >>In article <e15db$417c6020$cb248f0$62...@nf1.news-service-com>,
LD> >>
LD> >>These days it's simpler to put the whole OS installation into a single
LD> >>partition, I think. Then the /usr distinction becomes moot.
LD> >
LD> >That may be simpler, but it is *not* a good idea. Robert is *exactly*
LD> >correct. In addition to the above, it is not uncommon to have /usr
LD> >mounted read only, which provides some additional protection.
LD>
LD> Protection against what? The number one danger you have to worry about,
LD> by about an order of magnitude, is a hard disk crash. When the disk
LD> goes, all the partitions go, so partitioning doesn't help you any there.
This is not always the case. Often what happens is that a sector here
or a sector there goes. A total hard disk crash, *out of the blue* is
*relatively* rare. With a *small* root file system, the probablility is
that a dieing disk will more likely lose a sector in /usr, which can be
dealth with in SU mode (e2fsck -c).
Also there is protection from random *human* error and this includes
things like bumping the power or reset switch or yanking out the power
cord, etc. Since the core root partition rarely gets written to, there
is almost never anything for fsck to deal with -- this means that a
small root file system will pass a fsck quickly and cleanly. If /usr
(or /var) gets a random 'scribble' due to an odd power glitch (whether
from human error or say a power failure), the system *will* come up at
least enough to deal with things by hand if needed.
Lawrence DąOliveiro
Robert Heller <hel...@deepsoft.com> wrote:
> Lawrence DąOliveiro <l...@geek-central.gen.new_zealand>,
> In a message on Tue, 26 Oct 2004 18:43:53 +1300, wrote :
>
>LD> In article <87mzybm...@barrow.com>,
>LD> fl...@barrow.com (Floyd L. Davidson) wrote:
>LD>
>LD> >Lawrence DąOliveiro <l...@geek-central.gen.new_zealand> wrote:
>LD> >>In article <e15db$417c6020$cb248f0$62...@nf1.news-service-com>,
>LD> >>
>LD> >>These days it's simpler to put the whole OS installation into a single
>LD> >>partition, I think. Then the /usr distinction becomes moot.
>LD> >
>LD> >That may be simpler, but it is *not* a good idea. Robert is *exactly*
>LD> >correct. In addition to the above, it is not uncommon to have /usr
>LD> >mounted read only, which provides some additional protection.
>LD>
>LD> Protection against what? The number one danger you have to worry about,
>LD> by about an order of magnitude, is a hard disk crash. When the disk
>LD> goes, all the partitions go, so partitioning doesn't help you any there.
>
>This is not always the case. Often what happens is that a sector here
>or a sector there goes. A total hard disk crash, *out of the blue* is
>*relatively* rare. With a *small* root file system, the probablility is
>that a dieing disk will more likely lose a sector in /usr, which can be
>dealth with in SU mode (e2fsck -c).
I have never tolerated the use of a disk with bad sectors in a machine
doing anything of importance. If it has bad sectors, it's time to get
rid of it and reinstall anyway. So partitioning doesn't save you
anything.
>Also there is protection from random *human* error and this includes
>things like bumping the power or reset switch or yanking out the power
>cord, etc. Since the core root partition rarely gets written to, there
>is almost never anything for fsck to deal with -- this means that a
>small root file system will pass a fsck quickly and cleanly. If /usr
>(or /var) gets a random 'scribble' due to an odd power glitch (whether
>from human error or say a power failure), the system *will* come up at
>least enough to deal with things by hand if needed.
I have seen lots of crashes, some of which needed some pretty scary
fsck'ing to fix. But nothing where partitioning ever helped at all.
These days, with journalling, there is even less of a worry.
But hard disk crashes are just as likely as ever. And partitioning won't
save you from those.
Paul Black
> In article <ceaa4$417e4abf$cb248f0$32...@nf1.news-service-com>,
> Robert Heller <hel...@deepsoft.com> wrote:
>>This is not always the case. Often what happens is that a sector here
>>or a sector there goes. A total hard disk crash, *out of the blue* is
>>*relatively* rare. With a *small* root file system, the probablility is
>>that a dieing disk will more likely lose a sector in /usr, which can be
>>dealth with in SU mode (e2fsck -c).
>
>
> I have never tolerated the use of a disk with bad sectors in a machine
> doing anything of importance. If it has bad sectors, it's time to get
> rid of it and reinstall anyway. So partitioning doesn't save you
> anything.
With the way that IDE disks attempt to hide bad sectors (do SCSI disks
do this?) this is an important comment.
If bad sectors are showing up anywhere on the disk after writing then
the disk has run out of replacement sectors (which, IIRC, is about 0.5%
of the disk) then the disk should be considered duff. There is no
protection for damage to other sectors including sector 0.
--
Paul Black mailto:paul....@oxsemi.com
Oxford Semiconductor Ltd http://www.oxsemi.com
25 Milton Park, Abingdon, Tel: +44 (0) 1235 824 909
Oxfordshire. OX14 4SH Fax: +44 (0) 1235 821 141
Peter T. Breuer
> Lawrence D?Oliveiro wrote:
> > In article <ceaa4$417e4abf$cb248f0$32...@nf1.news-service-com>,
> > Robert Heller <hel...@deepsoft.com> wrote:
> >>This is not always the case. Often what happens is that a sector here
> >>or a sector there goes. A total hard disk crash, *out of the blue* is
> >>*relatively* rare. With a *small* root file system, the probablility is
> >>that a dieing disk will more likely lose a sector in /usr, which can be
> >>dealth with in SU mode (e2fsck -c).
> >
> >
> > I have never tolerated the use of a disk with bad sectors in a machine
> > doing anything of importance. If it has bad sectors, it's time to get
> > rid of it and reinstall anyway. So partitioning doesn't save you
> > anything.
>
> With the way that IDE disks attempt to hide bad sectors (do SCSI disks
> do this?) this is an important comment.
Well ..
> If bad sectors are showing up anywhere on the disk after writing then
But that's not the point. They will show up on READING them. THen you
have to write them (with the correct bytes :-) in order to "fix"
them. A new sector gets flipped in to the map on write.
> the disk has run out of replacement sectors (which, IIRC, is about 0.5%
> of the disk) then the disk should be considered duff. There is no
> protection for damage to other sectors including sector 0.
See above - you misreperesent the situation to some degree (well, so do
I, but less so !).
Peter
Harold Stevens
[Snip...]
> If bad sectors are showing up anywhere on the disk after writing then
> the disk has run out of replacement sectors (which, IIRC, is about 0.5%
> of the disk) then the disk should be considered duff.
I agree; IME, a grep for "Seek" errors is a good early-warning of errors:
grep Seek /var/log/messages
If this finds things like
aces kernel: hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
you better at least have backups, then plan on a replacement drive.
BTW, I see this (boot only) in SuSE 2.6.5-7.111-default (a boot DMA bug?).
--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
Kids jumping ship? Looking to hire an old-school type? Email me.
Robert Heller
In a message on Wed, 27 Oct 2004 20:01:47 +1300, wrote :
LD> In article <ceaa4$417e4abf$cb248f0$32...@nf1.news-service-com>,
LD> Robert Heller <hel...@deepsoft.com> wrote:
LD>
LD> > Lawrence DąOliveiro <l...@geek-central.gen.new_zealand>,
LD> > In a message on Tue, 26 Oct 2004 18:43:53 +1300, wrote :
LD> >
LD> >LD> In article <87mzybm...@barrow.com>,
LD> >LD> fl...@barrow.com (Floyd L. Davidson) wrote:
LD> >LD>
LD> >LD> >Lawrence DąOliveiro <l...@geek-central.gen.new_zealand> wrote:
LD> >LD> >>In article <e15db$417c6020$cb248f0$62...@nf1.news-service-com>,
LD> >LD> >>
LD> >LD> >>These days it's simpler to put the whole OS installation into a single
LD> >LD> >>partition, I think. Then the /usr distinction becomes moot.
LD> >LD> >
LD> >LD> >That may be simpler, but it is *not* a good idea. Robert is *exactly*
LD> >LD> >correct. In addition to the above, it is not uncommon to have /usr
LD> >LD> >mounted read only, which provides some additional protection.
LD> >LD>
LD> >LD> Protection against what? The number one danger you have to worry about,
LD> >LD> by about an order of magnitude, is a hard disk crash. When the disk
LD> >LD> goes, all the partitions go, so partitioning doesn't help you any there.
LD> >
LD> >This is not always the case. Often what happens is that a sector here
LD> >or a sector there goes. A total hard disk crash, *out of the blue* is
LD> >*relatively* rare. With a *small* root file system, the probablility is
LD> >that a dieing disk will more likely lose a sector in /usr, which can be
LD> >dealth with in SU mode (e2fsck -c).
LD>
LD> I have never tolerated the use of a disk with bad sectors in a machine
LD> doing anything of importance. If it has bad sectors, it's time to get
LD> rid of it and reinstall anyway. So partitioning doesn't save you
LD> anything.
I don't tolerate disks with bad sectors either. OTOH, I often have
files other than the base distro on the disk. So, when the disk starts
to go bad, it is good to get the machine up enough to transfer the data
to the new disk.
LD>
LD> >Also there is protection from random *human* error and this includes
LD> >things like bumping the power or reset switch or yanking out the power
LD> >cord, etc. Since the core root partition rarely gets written to, there
LD> >is almost never anything for fsck to deal with -- this means that a
LD> >small root file system will pass a fsck quickly and cleanly. If /usr
LD> >(or /var) gets a random 'scribble' due to an odd power glitch (whether
LD> >from human error or say a power failure), the system *will* come up at
LD> >least enough to deal with things by hand if needed.
LD>
LD> I have seen lots of crashes, some of which needed some pretty scary
LD> fsck'ing to fix. But nothing where partitioning ever helped at all.
LD> These days, with journalling, there is even less of a worry.
LD>
LD> But hard disk crashes are just as likely as ever. And partitioning won't
LD> save you from those.
Paul Black
> BTW, I see this (boot only) in SuSE 2.6.5-7.111-default (a boot DMA bug?).
We saw something similar on a SuSE machine. ISTR the cure was to get new
firmware for the Hitachi drives.
Paul
Harold Stevens
>> BTW, I see this (boot only) in SuSE 2.6.5-7.111-default (a boot DMA bug?).
>
> We saw something similar on a SuSE machine. ISTR the cure was to get new
> firmware for the Hitachi drives.
This happens to be a Compaq CDR-8335 (4.4 GB) so it's obviously old(er)
and its firmware may need similar mods. However, AFAICT it appears only
during the boot and nothing more until the next boot. So it doesn't get
me too worked up, or tweaking firmware. Yet. :)
Typically, these boot errors look something like (lines wrapped):
May 23 18:03:20 aces kernel: hda: drive_cmd: status=0x51 { DriveReady
SeekComplete Error }
May 23 18:03:20 aces kernel: hda: drive_cmd: error=0x04 { DriveStatusError }
May 23 18:03:21 aces [powersave_proxy][10735]: WARNING: hdparm returned error 5
May 23 18:03:21 aces kernel: hda: task_no_data_intr: status=0x51 { DriveReady
SeekComplete Error }
May 23 18:03:21 aces kernel: hda: task_no_data_intr: error=0x04
{ DriveStatusError }
Again, if a boot bug, no biggie at this point (to me); just curious.
Lawrence DąOliveiro
Harold Stevens <woo...@deuce.localdomain> wrote:
>IME, a grep for "Seek" errors is a good early-warning of errors:
>
> grep Seek /var/log/messages
>
>If this finds things like
>
> aces kernel: hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
>
>you better at least have backups, then plan on a replacement drive.
Urk. I've just found this in a couple of the machines I'm responsible
for.
I'm doing a more thorough test like this:
dd if=/dev/sda of=/dev/null
and logging any i/o errors reported.
Baard Ove Kopperud
> Why is there a /lib versus /usr/lib? /bin versus /usr/bin? /sbin versus
> /usr/sbin?
/lib, /bin and /sbin includes stuff you may need
in a single-user system (e.g. while recovering
from power-failure and such). It's what you
actually *need* in an OS, and plenty to get things
up-and-running (i.e. being able to mount /usr and
thus get access to the rest).
/usr/lib, /usr/bin and /usr/sbin don't *have to*
be available to get the system healthy again after
problems. There are nothing there you actually
need... plenty of convinient things, yes... but
nothing you *need*. Therefor, you don't *have to*
have /usr mounted to use your system.
> Why is there a /usr/share but no /share?
Originally, stuff that's now supposed to go
into */share used to be located in */lib... but
at some time they decided to seperate what is
specific to the arcitecture-type (e.g. i86, sparc,
alpha) from what is common for *all* (mostly
text-files of some sort). The machine-specific
things are still in */lib, while the common
things are in */share.
More importantly, that kind of shared-stuff are
not necessery to do the real basic stuff... you
don't *need* manuals, you don't *need* documentation
and there are no really big packages with lots of
stuff in shared you *need* (and if there were,
it could just as easely -- and *almost* as
correctly -- be placed under /lib)... all those are
not strictly necessery, and therefor goes into /usr/*
anyway.
In single-user mode -- which is when you *may* not
have access to /usr and /var -- you most likely will
just do recovery and basic administration anyway, and
you don't need GUI and complex-programs for doing that.
> /usr/local but not
> /local?
I've asked myslef that question... :-)
Usually /usr/local are used in one of two ways...
-Stuff from your distro goes into /usr... stuff you¨
add yourself (including source-code) goes into
/usr/local. You already have the stuff in /usr
on your distro-CD, so you only have to back-up
what you've added yourself -- the stuff in /usr/local.
-You share /usr among many machines, but use
/usr/local to add programs specific for *some*
machines. E.g. if you have one machine with a
scanner, installing scanning-programs and additional
programs for image-editing on just that machine
would make sense.
I've often thought though, that if you shared
/usr among many machines and wanted to add
something to be shared too, then it would
make sense to put what you've added into
/usr/local and let it be distributed with
/usr... but if you *also* wanted to install
something specific to just *one* machine,
then making a /local-directory with
/local/bin, /local/share and /local/lib would
seem like a logical thing to do.
> If something runs from /usr/bin or /usr/sbin instead of /bin or
> /sbin, why does its configuration live in /etc and not /usr/etc?
You can have a /usr/etc and /usr/local/etc, but they
should be a link to /etc.
The / (root) with /etc and the /var directories are
specific for each machine... the /usr (and some other
directories -- like /home and /var/mail) may be shared
among several machines.
Imagine you have six machines. You decide to let them
all share the same (read-only mounted) /usr. Imagine
you want to run web-servers on all of them... They'll
all read the binaries, libraries, non-arcitecture specific
stuff (/usr/share) -- like documentation -- from the
*same* /usr-partition.
However although they can run the same program, the
six machines will have different names which may affect
the configuration of each of the running web-servers.
You may also wish that different default-pages are shown
from each machine.
Fortunately both the cofiguration in /etc and the pages
and and additional configurations in /var are in
directories that are *not* shared... so you may configure
the web-server differently on each of the machines, and have
them all present different pages -- even though they all use
the same program from /usr.
If the pages were located in /usr/share and the configuration
actually *was* in /usr/etc (and /usr/etc wasn't just a link
to /etc), then you would have had to run the programs from a
shared /usr-partition with the exact same configuration
for all the machines.
-Koppe
Lawrence DąOliveiro
baard.k...@bigfoot.com (Baard Ove Kopperud) wrote:
>In single-user mode -- which is when you *may* not
>have access to /usr and /var -- you most likely will
>just do recovery and basic administration anyway, and
>you don't need GUI and complex-programs for doing that.
But you will frequently need to refer to man pages, won't you? At least,
I certainly do. But those are located in /usr/share/man, which wouldn't
be accessible.
>The / (root) with /etc and the /var directories are
>specific for each machine... the /usr (and some other
>directories -- like /home and /var/mail) may be shared
>among several machines.
>
>Imagine you have six machines. You decide to let them
>all share the same (read-only mounted) /usr. Imagine
>you want to run web-servers on all of them... They'll
>all read the binaries, libraries, non-arcitecture specific
>stuff (/usr/share) -- like documentation -- from the
>*same* /usr-partition.
But they can't share binaries in /bin and /lib?
Bill Unruh
]In article <ae685d1b.04102...@posting.google.com>,
] baard.k...@bigfoot.com (Baard Ove Kopperud) wrote:
]>In single-user mode -- which is when you *may* not
]>have access to /usr and /var -- you most likely will
]>just do recovery and basic administration anyway, and
]>you don't need GUI and complex-programs for doing that.
]But you will frequently need to refer to man pages, won't you? At least,
]I certainly do. But those are located in /usr/share/man, which wouldn't
]be accessible.
You can mount them if you wish.
mount /usr
and then they are accessible.
Alexander Skwar
> But you will frequently need to refer to man pages, won't you?
Not neccessarily on the machine that's being fixed. And
quite often (ie. *NOT* always) the --help output is good enough.
Alexander Skwar
--
printk(KERN_WARNING "Hey who turned the DMA off?\n");
linux-2.6.6/drivers/net/wan/z85230.c
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Baard Ove Kopperud
No.
For one thing most of the network-stuff are in /usr...
in single-user mode -- without /usr -- you're usually
working without a network anyway... and only the most
basic network commands (like what you need to mount
/usr over the network) is availble.
Secondly, you'll need things in /lib, /sbin and /bin even
*before* the network is accessable -- for one thing, you'll
need the programs and libraries for *starting* the network.
If /bin, /sbin and /lib was suppoesed to be mounted over
the network, you wouldn't be able to mount them, because
the programs you'd need to that wasn't avaible... they
would be in what you wanted to mount!
Also, where would you start the network from? To display
things on the screen, you need stuff that are in /lib...
to order the network mounted, you need a shell -- but they're
all in /bin... what if something was wrong with the network?
You wouldn't be able to get your machine up-and-running
enough to even serach for errors!
Fortunately, the stuff in /lib, /bin and /sbin takes very
little space compared to all the stuff in /usr, so you don't
really waste that much by having it repeated on all machines...
-Koppe
Lawrence DąOliveiro
un...@string.physics.ubc.ca (Bill Unruh) wrote:
So what is the point of having to go to this extra step?
Robert Heller
In a message on Fri, 29 Oct 2004 13:13:53 +1300, wrote :
LD> In article <ae685d1b.04102...@posting.google.com>,
LD> baard.k...@bigfoot.com (Baard Ove Kopperud) wrote:
LD>
LD> >In single-user mode -- which is when you *may* not
LD> >have access to /usr and /var -- you most likely will
LD> >just do recovery and basic administration anyway, and
LD> >you don't need GUI and complex-programs for doing that.
LD>
LD> But you will frequently need to refer to man pages, won't you? At least,
LD> I certainly do. But those are located in /usr/share/man, which wouldn't
LD> be accessible.
Well, if there are problems, you just have to live without. Functioning
in SU mode from a 'rescue' type system (eg withOUT the 'luxury' of
/usr), is an expert-mode type of situation -- presumably if you are
working in such an environment you have the man pages pretty much
memorized or at least the man pages for the handful of utilities you
will be using, must of which will spit some sort of 'help' when run with
out any command line args (a usage line at least). The commands
typically used in this situation are not particularly complicated and/or
don't have a complex CLI interface.
LD>
LD> >The / (root) with /etc and the /var directories are
LD> >specific for each machine... the /usr (and some other
LD> >directories -- like /home and /var/mail) may be shared
LD> >among several machines.
LD> >
LD> >Imagine you have six machines. You decide to let them
LD> >all share the same (read-only mounted) /usr. Imagine
LD> >you want to run web-servers on all of them... They'll
LD> >all read the binaries, libraries, non-arcitecture specific
LD> >stuff (/usr/share) -- like documentation -- from the
LD> >*same* /usr-partition.
LD>
LD> But they can't share binaries in /bin and /lib?
Yes and no. In theory, yes, but there is a chicken and egg problem: how
do you load the kernel (and the nfsd module) *before* /bin and /lib are
nfs mounted? Yes, you can have way too much fun with ramdisks and it
quite possible to run totally diskless machines, but if you do have a
(small) local disk, you might as well have enough on it to run in single
user mode.
Baard Ove Kopperud
> In article <cls47g$ola$1...@nntp.itservices.ubc.ca>,
> un...@string.physics.ubc.ca (Bill Unruh) wrote:
>
> >Lawrence DąOliveiro <l...@geek-central.gen.new_zealand> writes:
> >
> >]In article <ae685d1b.04102...@posting.google.com>,
> >] baard.k...@bigfoot.com (Baard Ove Kopperud) wrote:
While man-pages are nice to have, they're mot strictly
necessery.
> So what is the point of having to go to this extra step?
Because sometimes you can't get any further! Perhaps
the partition containing /usr is damaged so you can't
mount it... then the root (/) is *all* you have, and
everything you need to fix and mount the damaged /usr-partiotion
*must* be available there. The same goes if you made an error
in a config-file preventing you to reach a higher runlevel...
then you *need* something to let you edit the config-file
and to later get the system up to a higher runlevel.
+++
The point of /bin, /lib and /sbin, is to give you just
enough tools to use while (possibly) working in single-user
and without the network, to get your system up-and-running.
That is, stuff to check, create and mount filesystems,
partisionate the drive, edit config-files, install things
you're missing, getting some basic networking going perhaps,
and taking the system up to higher runlevels.
Once there (in a higher runlevel) or once mounted, you have
man-pages and everything else...
The point is, that the stuff on the root (/bin, /sbin, /lib)
is the the stuff you absolutly can't do without. Stuff that
you absolutly *will* need if you fail to reach a higher
runlevel or fail to mount a partition. The stuff here, is
what the system needs *before* mounting other partitions
and/or reaching a higher run-level, and what you may need
to find errors and repair your system so your able to
mount or reach higher runlevels.
-Koppe
Lawrence DąOliveiro
Robert Heller <hel...@deepsoft.com> wrote:
> Lawrence DąOliveiro <l...@geek-central.gen.new_zealand>,
> In a message on Fri, 29 Oct 2004 13:13:53 +1300, wrote :
>
>LD> In article <ae685d1b.04102...@posting.google.com>,
>LD> baard.k...@bigfoot.com (Baard Ove Kopperud) wrote:
>LD>
>LD> >In single-user mode -- which is when you *may* not
>LD> >have access to /usr and /var -- you most likely will
>LD> >just do recovery and basic administration anyway, and
>LD> >you don't need GUI and complex-programs for doing that.
>LD>
>LD> But you will frequently need to refer to man pages, won't you? At least,
>LD> I certainly do. But those are located in /usr/share/man, which wouldn't
>LD> be accessible.
>
>Well, if there are problems, you just have to live without.
Well, I most certainly would not tolerate such a situation. If in doubt
over the meaning of an option, I'd prefer to check the man page rather
than taking a guess--especially when running as root!
>LD> >The / (root) with /etc and the /var directories are
>LD> >specific for each machine... the /usr (and some other
>LD> >directories -- like /home and /var/mail) may be shared
>LD> >among several machines.
>LD> >
>LD> >Imagine you have six machines. You decide to let them
>LD> >all share the same (read-only mounted) /usr. Imagine
>LD> >you want to run web-servers on all of them... They'll
>LD> >all read the binaries, libraries, non-arcitecture specific
>LD> >stuff (/usr/share) -- like documentation -- from the
>LD> >*same* /usr-partition.
>LD>
>LD> But they can't share binaries in /bin and /lib?
>
>Yes and no. In theory, yes, but there is a chicken and egg problem: how
>do you load the kernel (and the nfsd module) *before* /bin and /lib are
>nfs mounted?
The kernel and initrd reside in /boot.
Baard Ove Kopperud
> In article <ee874$41821e6b$cb248f0$15...@nf1.news-service-com>,
> Robert Heller <hel...@deepsoft.com> wrote:
> >LD> But you will frequently need to refer to man pages, won't you? At least,
> >LD> I certainly do. But those are located in /usr/share/man, which wouldn't
> >LD> be accessible.
> >
> >Well, if there are problems, you just have to live without.
>
> Well, I most certainly would not tolerate such a situation. If in doubt
> over the meaning of an option, I'd prefer to check the man page rather
> than taking a guess--especially when running as root!
True, but some times you have to fix things first,
so knowing what you'll need about some essential
commands is important.
> >Yes and no. In theory, yes, but there is a chicken and egg problem: how
> >do you load the kernel (and the nfsd module) *before* /bin and /lib are
> >nfs mounted?
>
> The kernel and initrd reside in /boot.
But the kernel-modules and such are in /lib...
And the commands you need to get started -- like a shell,
editor, e2fsck, mount and so on -- are in /bin and /sbin.
-Koppe