In <[EMAIL PROTECTED]>, Michael R. Wayne <[EMAIL PROTECTED]> typed:
> On Thu, Jul 27, 2006 at 02:28:18PM -0400, Mike Meyer wrote:
> > These days, the only technical reason I know of for having separate
> > mountpoints is because you want to run commands that work on
> > filesystems on the two parts with different arguments or under
> > different conditions.
> Or you want to run a bunch of jails.
You don't need mount points to run jails. In fact, the man page (on
5.5, anyway) provides examples that *break* if you put the jails on a
separate mount point.
> Or you want to give a bunch > of users a big chunk of space and
> quotas are a bad fit.
That's a social reason, not a technical one. That used to be really
common as well, but these days "a bunch of users" tend to get their
own machine.
In <[EMAIL PROTECTED]>, Alex Zbyslaw <[EMAIL PROTECTED]> typed:
> Mike Meyer wrote:
> >In <[EMAIL PROTECTED]>, Rick C. Petty <[EMAIL PROTECTED]> typed:
> >>On Thu, Jul 27, 2006 at 09:49:48AM -0400, Steve Ames wrote:
> >>>On Thu, Jul 27, 2006 at 02:21:59PM +0200, Joerg Sonnenberger wrote:
> >>>>DragonFly disklabels allow 16 entries by default, FreeBSD still limits
> >>>>it to 8. That's why you can't read it directly.
> >>>Are there plans to bump the default up from 8? I'm honestly torn on
> >>>this topic whenever I install a new system. On the one hand I like
> >>>having a lot of discrete mountpoints to control potential usage. On
> >>>the other hand with drive space being so inexpensive I sometimes
> >>>wonder if I need to bother and can get away with very few mountpoints.
> >>I would think that cheap disk space would mean larger disks which implies
> >>more mountpoints ???
> >Nope. One of the historical uses of partitions was to act as firewalls
> >between subsystems, so that subsystem A running out of space didn't
> >cause subsystem B to die for lack of space. This had the downside of
> >making it more likely that one of the two would run out of space
> >because the excess space from another subsystem could only be used by
> >it. With cheap disk space, you overallocate by enough to give you
> >plenty of warning before you have to deal with the issue. You can
> >safely share that space, and doing so means you have to "deal with the
> >issue" less often.
> You assume that "running out of space" happens over time, but with some
> runaway process logging to a file, for example, the partition filling up
> will still happen without you expecting it. It might take a bit longer
> with a big disk, but 20 minutes instead of 5 minutes isn't much
> different in terms of warning.
Yes, I'm assuming that "running out of space" happens over
time. Sustained I/O speeds on modern hardware was around 100MB/sec
last time I looked. So a good, large disk - say a terabyte raid (you
need raid to get those performance numbers, so call it 2 500GB disks
to keep it simple) - will take about three hours to fill *if you do
nothing but write to the disk*. A runaway process - especially one
generating log data - is normally doing other things that it's trying
to log information about.
A typical installation will have smaller, slower disks. A high-end
installation with faster disks will almost certainly have lots more
space as well. So it's perfectly reasonable to rely on disks to not
fill up in a matter of minutes.
In practice, log files are several orders of magnitude smaller than
the actual data dealt with by most application. A few hundred
megabytes is more than adequate log space for most systems, with
runaway processes filling them in a day or so. So I give those systems
a gigabyte of log space, 'cause disk is *cheap*.
And yes, I separate /var from /home and /usr, but not because I'm
worried about them running out of space.
> Fill /tmp or /var and many things can fail. Fill /home and it's just
> users who suffer a little but mail, demons etc. just carry on.
You're being inconsistent. Log files normally go on /var, so if you
fill that, your demons may well fail, depending on how they react to
not being able to log messages. On the other hand, for some demons it
makes sense to treat their data just like any other user data, so
they'd be on /home, and suddenly they're failing when /home fills up.
I had a system fall over for lack of disk space this month. It was an
old system, that only had 16GB of disk for file storage, and the 300GB
drive upgrade had already been ordered. It's a four-core 3GHz opteron
system, doing ETL processing as fast as it's little chips can
cycle. It took *five hours* to fill up when half of the data started
collecting on it instead of being loaded into the database. If it had
had the disk upgrade, it would have take a couple of days.
> A further reason to separate partitions is that dump works at the level
> of a partition. Different partitions may have very different backup
> requirements, and for those of us without huge tape drives, partitioning
> to a size that can be dumped on one tape makes life easier.
That's one of the technical reasons I mentioned in the part you
didn't quote.
> In some environments, fewer partitions may indeed be the new norm, but
> in others it would not.
And in some environments, Windows is the norm. The question is - is
there still a good technical reason for doing that? The two primary
technical reasons I used to create partitions (firewalls for space and
damage) are both pretty much dead.
> Personally, I would like a limit of 16. It would mean that I could fit
> all my regular partitions inside a single slice, freeing up other slices
> for, for example, experimenting with 64-bit, or -current, or whatever.
> Bootable FreeBSD slices will be stuck at 4 for the foreseeable future -
> extending the number of partitions within a slice frees up slices, which
> are the really limited resource.
Why do you need lots of partitions for experimental systems? And if
you need that, how often is it actually a win to give up the unlimited
number of logical volumes you get in an extended partition to get one
(1) extra bootable FreeBSD partition? Especially if some of the
system you want to experiment with aren't as limited FreeBSD, and can
boot off of logical volumes? Frankly, if you're really worried about
bootable slices, you should be advocating giving FreeBSD the ability
to boot from a logical volume. IIRC, someone did that once, but never
got it into the tree.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
