Re: disklabel differences FreeBSD, DragonFly

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
didn't quote.


To my mind, it only takes *one* technical reason. If I need multiple partitions to make backups easy, then arguments about log files are irrelevant :-)



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
between them.


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 *** 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
so on....


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
aren't bootable,

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).

--Alex


_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"