One or Four?

[Da Rock]

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.