disklabel differences FreeBSD, DragonFly
xfb52 at dial.pipex.com
Fri Jul 28 00:01:03 UTC 2006
Mike Meyer wrote:
>>>>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
>>To my mind, it only takes *one* technical reason. If I need multiple
>>partitions to make backups easy, then arguments about log files are
>If you're going to count 1, 2, many, then we already have "many"
>partitions, and don't need more. Once you get into finer distinctions
>of "many", you need to figure out which reasons are actually valid,
>and which are spurious, so you can pick from among those manys.
I have no real idea what this means, sorry. It seems to me that whoever
made the initial decision to stop at 8 (size of an integer?) clearly
thought counting past 2 was worthwhile. Maybe the original reasons no
longer apply since quite a lot has changed since then :-)
>>>Well, there are always special cases. But hardware is so cheap these
>>>days, I'm used to fine-tuning the *system*, not just the partition.
>>>If something is so critical that it needs it's own partition, it's
>>>probably so critical that it needs it's own system as well. In fact,
>>>most of the thing I work on these days are so critical that they need
>>>several systems, half of them at a second site with automatic failover
>>Not everyone is in a position to throw money at everything and what's
>>cheap to you isn't cheap to everyone.
>Boxes are cheaper than disk space - my last two low-end boxes cost
>less than my last small disk drive, even though I ordered them all
>about the same time. If you can afford the disk for some process, then
>chances are good you can afford a system instead, or as well.
I don't understand this either. Surely the box has to include the disk
space so how can it cost less? If it costs less because it's a cheap
piece of junk, why would I even want it?
And the "cost" of the system doesn't stop at the up front price -
running costs including maintaining the box surely count (not to mention
that I have nowhere to put the damn thing). And I'm not sure where
needing a separate partition and criticality became the same thing. I
don't claim to want or need separate partitions because any particular
subset of the filesystem is critical, but because I want it to be
separate for at least the two reasons outlined below.
>>I can't possibly justify one system for everything that needs a
>>partition, nor do I even feel the need to do that. If anything, it
>>would be a major inconvenience.
>My claim is that your "everything that needs a partition" probably
>includes things that don't. But to prove that, we need to examine the
>reasons you think those things need a partition. I believe the only
>one you've given so far - as a space firewall - is specious.
Except that we also have the "dump", and the "different params for
different parts of the filesystem" arguments. I think you agreed that
you counted those as technical reasons.
>Your arguments remind me of the environments I worked on in the 70s
>and 80s. Minis and mainframes that did all the computing for an
>organization. All the daemons that talked to the outside world ran on
>the same box as the developers ran compiles and tests on, etc. While
>that worked really well when it came to generating a robust OS, I
>haven't seen an environment like that in decades. Hell, most of my
>clients would shit bricks at the thought of putting their source or
>data on a machine that could be reached from the internet at large at
>all. Every developler has a box - or three - on their desks. The ETL
>boxes are distinct from the database boxes are distinct from the
>internal mail server is distinct from the external mail server,
>etc. If I want to have a process send email notices about something, I
>usually have to beat on them if I want a mail server on the box. And
Fine. You have access to lots of money and infrastructure. I don't.
Throwing money at a problem is not a solution available to everyone.
>>>Frankly, if you're really worried about
>>>bootable slices, you should be advocating giving FreeBSD the ability
>>>to boot from a logical volume.
>>Who said I didn't? I have no objection to such a facility and would
>>welcome it. It just imagined that extending the number of partitions
>>from 8 to 16 would have been easier than booting from logical slices.
>>If booting from logical slices is easier then I'm all for it.
>You're not asking the right question just yet. The question shouldn't
>be "which is easier to add", but "which provides the most benefit for
>the least pain" (which subsumes the pain involved in adding it). I
>believe that the benefits of adding more partitions per slice are
>minimal - there are at least three ways to add more file systems that
>aren't bootable, and there's a better fix to the problem of wanting
>more bootable partitions - and the pain involved in upgrading a system
>across a change in the bsdlabel would be rather high.
This all sounds fine to me, though the OP who wanted to mount a
DragonFly partition might disagree :-(
The bottom line for me is this: if the number of partitions per slice
were to increase from 8 to 16, that would make my life easier as I do
things now. The way I do things now works very well for me. and nothing
you have said tells me how I could do things differently and still have
it work as well. If no-one is going to increase partitions from 8 to
16, I'll survive. If someone instead makes logical partitions bootable,
I'd be happy too. If someone comes up with something completely
different that makes it easier for me to boot multiple FreeBSD's on a
single machine without a) adding extra disk or b) buying expensive
software, I'd be thrilled to bits.
>there are at least three ways to add more file systems that
Logical partitions. What would be your other two? (Off list, if you
prefer and can be bothered to answer, since it has got rather OT).
More information about the freebsd-hackers