Date: Sat, 18 Feb 2012 11:00:05 +1000 From: Da Rock <freebsd-questions@herveybayaustralia.com.au> To: freebsd-questions@freebsd.org Subject: Re: One or Four? Message-ID: <4F3EF815.4070000@herveybayaustralia.com.au> In-Reply-To: <4F3EF6EA.6070805@herveybayaustralia.com.au> References: <4F3ECF23.5000706@fisglobal.com> <20120217234623.cf7e169c.freebsd@edvax.de> <20120217225329.GB30014@gizmo.acns.msu.edu> <021101ccedc9$89445cf0$9bcd16d0$@fisglobal.com> <290E977C-E361-4C7D-8F1E-C1D6D03BAD63@mac.com> <021501ccedd1$ef4201d0$cdc60570$@fisglobal.com> <FF97816E-74EE-434C-BB04-A8F21C07AF10@mac.com> <4F3EF6EA.6070805@herveybayaustralia.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3EF815.4070000>