Date: Thu, 23 Sep 2004 20:45:29 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Garance A Drosihn <drosih@rpi.edu> Cc: freebsd-current@freebsd.org Subject: Re: Default support for GPT Message-ID: <200409240345.i8O3jTnd065936@apollo.backplane.com> References: <408F11C5.5030403@freebsd.org> <Pine.NEB.3.96L.1040427220746.51265D-100000@fledge.watson.org> <20040428033948.GA7603@dhcp01.pn.xcllnt.net> <20040921221631.GA14566@odin.ac.hmc.edu> <p06110414bd79413ef524@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
:At 5:48 PM -0700 9/23/04, Matthew Dillon wrote:
:>
:> I considered GPT but I want to have much more control over the
:> DragonFly 'partitions' then I believe GPT offers. e.g. we need
:> to be able to uniquely identify partitions in a WAN environment,
:> store the core RAID topology, and so on and so forth... everything
:> you need to operate in a clustered environment really has to be
:> made part of the partition table.
:
:What would that mean for people who like to setup multi-boot
:situations, though? Will dragonfly require that all partitions
:on a disk be dragonfly-format? Could you go with GPT for the
:initial partition table, and then store all the extra info that
:you want at the start of each partition?
No, but access to other OS's partition tables would of course depend on
whether code is written to support those tables, and they would not be
exportable in a distributed clustered environment (where pieces of the
RAID are strewn across several machines). But since they aren't likely
to be distributed partitions anyway that isn't a big deal, you would
still be able to export them via NFS or samba just like you always could
before.
I would definitely not want to try to separate the cluster control
info from the partition table. For one thing it makes importing third
party filesystems difficult (to say the least), because you are intruding
on the filesystem's storage space. The only other alternative would be to
store the information in a file, e.g. like in /etc, but then it is no
longer bound to the physical disk containing the data which can result
in truely horrendous mixups.
The last thing you would ever want to do would be to store the unique
identifier and RAID topology from the physical partition table being
distributed. Even keeping track of e.g. the drive serial number is
not sufficient. Being able to pull a physical drive and move it from
one machine to another, or even to a remote machine not on the local
LAN, and still have the cluster be able to piece itself together, is
very important.
You can also consider portable storage in this light... plug it in
*anywhere* on the internet and it can theoretically be reconnected to
its cluster *anywhere else* on the internet. We aren't talking about
a few bytes here, we are talking potentially a kilobyte of information
per partition that needs to be kept with that partition, possibly even
more.
:And as I sit here installing a new machine, I also wonder if you
:should pick a different partition-type for Dragonfly, just so you
:don't have to worry about matching future UFS/UFS2 changes.
You mean a different sysid in the slice table? I've considered it.
It makes sense, but it isn't at the top of the list.
-Matt
Matthew Dillon
<dillon@backplane.com>
:--
:Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
:Senior Systems Programmer or gad@freebsd.org
:Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409240345.i8O3jTnd065936>