Skip site navigation (1)Skip section navigation (2)
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>