On 02/18/12 10:55, Da Rock wrote:
On 02/18/12 10:40, Chuck Swiger wrote:
On Feb 17, 2012, at 4:11 PM, Devin Teske wrote:
However, for whatever reasons, the overwhelming majority of folks
using MacOS
X don't have problems using a single root partition, and while they
sometimes do
fill up their disks, that's a situation which they should be able
to recover from
without needing expert assistance. I don't recall having unusual
issues in running
a partition out of space under FreeBSD, either, or difficulty
fixing things
afterwards--
Recipe for disaster:
1. You have a cron-job that pulls down /etc/master.passwd daily
2. Your cron-job also runs pwd_mkdb after "SUP"ing down
/etc/master.passwd
Yes, I agree that this is a recipe for disaster; the reasons not very
correlated to disk space, however.
Even twenty years ago, handling this via YP/NIS or NetInfo would have
made more sense, and nowadays folks would be far more likely to use
LDAP as the network user database, instead of pushing system password
database changes via SUP or similar replication mechanism locally to
individual hosts.
3. A program fills "/"
4. cron fires
5. pwd_mkdb can't generate databases because not enough room on
filesystem
6. System can no longer be logged into
#5 does not imply #6: if pwd_mkdb can't build a temporary version to
/etc/pwd.db.tmp& /etc/spwd.db.tmp, it will exit with an error rather
than invoke rename(2) to replace the working version of the password
database with something that might be broken.
To be very specific, I would expect one to get:
"/: write failed, filesystem is full
pwd_mkdb: /etc/pwd.db to /etc/pwd.db.tmp: No space left on device"
7. System is rebooted
8. Can't log in (not even as root)
9. Go into single-user mode
10. No space to work in
Sure... you can call it an "edge-case," but it's pretty common and
this is only
one of a myriad of ways we can reproduce the problem of filling-up
"/" to cause
major headaches.
I've never heard of such a thing happening to a real FreeBSD system
in the past decade or more. The closest match to the issue results
in a failure of adduser(8) or pw(8) to add new users, but existing
users continued to work fine.
These are edge cases that _do_ happen - Linux (heaven forbid!) is
reknown for the all /, and I've been unable to boot properly into it
with a full disk. I had to use a live disk to rescue it which took
hours thanks to the $%^&! lvm filesystem.
Its just so easy to run a multi partition as opposed to an all /. And
how much does it cost/hurt to do it (especially given the inordinately
large hdd's these days)? Next to nix (pardon the pun :) ). The
reduction in problems for new users should be an incentive as well.
As for how quickly a disk can fill - I'm an expert :) I can fill a
terabyte disk in a matter of hours with video and not notice. The
transfers can be tricky to coordinate seeing as the disk fills faster
than I can move the large files to another filesystem.
And I haven't even mentioned some of the games that I'm sure a novice
desktop user will use...
You don't have to necessarily 'hose' the system to render it unusable.
Just have some obscure program or service that requires something like
a temp file or the like to stop it from working, and make it difficult
to find whats wrong.
I forgot to mention that the probable reason you haven't heard of any
such problems on real FreeBSD _is_ because it doesn't use the all /, or
a qualified sysadmin is watching over it.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
