disklabel differences FreeBSD, DragonFly

[Alex Zbyslaw]

Mike Meyer wrote:

>In <20060727180412.GB48057 at megan.kiwi-computer.com>, Rick C. Petty <rick-freebsd at kiwi-computer.com> 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.  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.

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.

In some environments, fewer partitions may indeed be the new norm, but 
in others it would not.

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.

I have no real idea how hard it would be to extend from 8 to 16, but if 
the effort required were reasonably low, then it would get my vote.

--Alex