Date: Wed, 04 Feb 2009 16:28:57 +0100 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-current@freebsd.org Subject: Re: GEOM_PART: a quick update on logical partitions Message-ID: <gmcc86$1o0$1@ger.gmane.org> In-Reply-To: <b649e5e0902040623g2ff69efevda99db6818db345c@mail.gmail.com> References: <FCA8C5E4-BC41-4711-9EBC-CD692144F6B8@mac.com> <20090203082153.565746e2@zelda.local> <b649e5e0902030357k7508b4e7kc69c31a354b3e077@mail.gmail.com> <gm9fh1$4el$1@ger.gmane.org> <b649e5e0902040623g2ff69efevda99db6818db345c@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Marius Nünnerich wrote: > On Tue, Feb 3, 2009 at 2:06 PM, Ivan Voras <ivoras@freebsd.org> wrote: >> Marius Nünnerich wrote: >> >>> I'm not happy with the symlinks either. When someone is manipulating a >>> partition table she should be able to live with the consequences. I >>> would rather go for the UUID in UFS header approach if there is enough >>> room. BTW I implemented GPT UUID glabels a while ago please see: >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=128398 >> I have a patch for UFS "GUID" labels (not exactly GUIDs, but every UFS >> file system has a reasonably unique ID associated with it) but have >> encountered what seems a bug in GEOM slicers - two dev entries pointing >> to the same device don't work well with orphaning/tasting. Have you >> encountered something similar perhaps? > > I haven't encountered strange behaviour there but I will test it again. I've read the code in the referenced PR and I see you've taken a different way to implement it than I did, but the problem might still be present; try the following sequence of operations: * create a geom (GPT slice in your case) that has two /dev entries on it - one from the GPT label and one from GPT GUID * mount one of those /dev entries (i.e. open it for exclusive access) - the other one should disappear * unmount it * see if the labels are correctly created (tasted) again. * repeat with the base device (on which GPT is created) - both labels should be spoiled and detected again If you see what I'm seeing (labels not correctly tasted) then it could be a problem. If not, it's my problem :) [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFJibRBldnAQVacBcgRAoniAJjDbD+x9xWQisUBfYVNtwMiT+iwAJ9nSRvg ZXQj4lkQ0GxiGtetT+ZYZQ== =8K4f -----END PGP SIGNATURE-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?gmcc86$1o0$1>