Re: disklabel differences FreeBSD, DragonFly

In <20060727185721.GC25626@xxxxxxxxxxxxxx>, Michael R. Wayne <wayne@xxxxxxxxxxxxxx> 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 <44C910BE.9000108@xxxxxxxxxxxxxx>, Alex Zbyslaw <xfb52@xxxxxxxxxxxxxx> typed:
Mike Meyer wrote:
In <20060727180412.GB48057@xxxxxxxxxxxxxxxxxxxxxxx>, Rick C. Petty <rick-freebsd@xxxxxxxxxxxxxxxxx> 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 <mwm@xxxxxxxxx> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Dangerously Dedicated (was: How do I create large ...)
    ... are called "compatibility mode" and "dedicated ... The use of slices - "DOS primary partitions" has often been ... "If the disk is going to be truly dedicated to FreeBSD, ...
    (freebsd-questions)
  • LVM on SW RAID for sarge - success
    ... I've just had success migrating Debian Sarge to root on LVM on RAID. ... First make sure the SCSI BIOS boots from the first disk. ... I made reiserfs on all the filesystem partitions and completed the ... The remaining two disks were partitioned and used to create RAID arrays ...
    (Debian-User)
  • Re: Replace SCSI Drive
    ... from there you can manipulate other hard drives attached to the machine. ... It should 'just work' but watch out that you keep disk devices ... vi-a) Write a BSD partition table into the slice, then set up your required FreeBSD partitions: ... items under the 'Custom Install' to achieve the desired result. ...
    (freebsd-questions)
  • Re: RAMDisk and HardDisk strikes back!
    ... One disk with only one partition as large as FBA setup; ... Two disk with one or more partitions for each. ... @ 20:32:55.252 #W059 Selecting best compatible driver failed. ... @ 20:53:51.166 #T211 Install Device: Changing registry settings as specified ...
    (microsoft.public.windowsxp.embedded)
  • Re: backups & cloning
    ... dump unmounted file systems to the system's tape drive. ... The restore program, on the other side of the | pipe, does ... Here's an example (ad1 is source disk, ... Use dump only on unmounted partitions. ...
    (freebsd-questions)