Date: Sun, 12 Nov 2000 23:28:48 -0600 (CST) From: Mike Meyer <mwm@mired.org> To: "Mathias Körber" <mathias@koerber.org> Cc: questions@freebsd.org Subject: RE: More partitions on a single slice? Message-ID: <14863.31760.496632.381103@guru.mired.org> In-Reply-To: <84596179@toto.iv>
next in thread | previous in thread | raw e-mail | index | archive | help
Mathias K=F6rber <mathias@koerber.org> types: > > > I like partitioning off this data to prevent eating others' (othe= r > > > users', applications' etc) space. If I use symlinks this happens = =3D > more > > > easily. > >=3D20 > > That's what quotas are for. > Quotas apply on a per user basis, not on a per-application basis. > If I have several users working on the same application etc, > I'd have to restrict them separately for this (and if the app > lived on the same FS as eg /home, then I'd simultaneously > restrict them in their /home, as quotas are only as granular as your > filesystem). Can you use group quotas for this? I consider quotas to be evil, because I typically want to limit *organization*, not people. > > Agreed, servers are a special case (and yes, I've seen laptop based= > > servers :-) In any such case, you need to consider exactly what you= 're > > doing, based on actual and expected load amongst other things. > But why then have this arbitrary restrictions in the first place? It went into place when hard disks were large (14 inches or larger), but the data on them was measured in kilobytes. For those disks, you can't afford to waste space on arbitrary partitions. In 25 years of managing Unix systems, I've never needed more than 7 partitions on a disk (and these days, you get 8). I've watched nearly every other such limit get changed: I've managed systems that used the group field everywhere it showed up as extra bits on the userid field to get enough users; I've cloned device drivers to new major numbers becase there weren't enough bits for all the drives on the system; I've replaced the getpw* routines because we had so many users it was taking *minutes* to get a prompt after entering a password - but I've *never* seen a system run out of partitions. Even when CSRG rewrote the file system (going from ufs to ffs), nobody saw any *need* to raise that limit. Further, the disklabel is not something one change lightly. Why do you think it's still got spooge like RPM and geometry information in it? Mathias K=F6rber <mathias@koerber.org> types: > > > I'm attaching a draft of the corresponding text from the coming =3D= > fourth > > > edition of "The Complete FreeBSD". This isn't set in stone, and > > > detailed comments are welcome. > >=3D20 > > Grr. Forgot the attachment *again*. If my attention span is up to= > > it, it should be attached now. > Thanks. Got it. Disagree with lots in it :-) > Mostly this: >=20 > =09As a result, I now recommend: >=20 > =09o Make a single root file system of between 2 and 4 GB. >=20 > =09o Do not have separate /usr or /var file systems. >=20 > =09o Use the rest of the space on disk for a /home file system, as= long =3D > as it's > =09 possible to back it up on a single tape. Otherwise make =3D= > multiple file > =09 systems. /home is the normal directory for user files. > Putting /var into the same fs as / and /usr is not a very good idea. = =3D > /var was split > off /var (and /) for *variable* data precisely so that / and /usr can= be =3D > made ro, and Actually, /var was split off to hold data that varied from machine to machine, so that sharing /usr wasn't quite so much of a pain. Most of the stuff that is now on /var used to be on /usr (/usr/tmp, /usr/spool, /usr/adm, and so on). However, wanting to make / & /usr ro is a valid reason for wanting /var split from /. That means you need four partitions (/, /var, /home & swap), leaving you twice as many as you need. > that excessive error logging (in case of system troubles, attacks etc= ) =3D > does not > fill up / and /usr and thus create more problems. Filling up / and /usr doesn't create problems. As far as the system is concerned, / and /usr being full is no different from them being ro, and they're so close to that that you're talking about *running* them that way. The reason to split /var off on servers is so that core files, kernel installs, and such-like spooge filling up / doesn't cause you major headaches by screwing up system logging. It causes you minor headaches when you're in the middle of system maintenance, and realize you can't install the new <whatever> because you're out of space. =09<mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14863.31760.496632.381103>