[Top] [All Lists]

Re: Proposal/RFC: new metadata-specific UUID for V5 supers

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: Proposal/RFC: new metadata-specific UUID for V5 supers
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 30 Apr 2015 07:27:56 +1000
Cc: xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <5541253D.4090701@xxxxxxxxxxx>
References: <553EB3D1.10602@xxxxxxxxxxx> <20150427233754.GT21261@dastard> <553ED9D8.4050106@xxxxxxxxxxx> <20150428012003.GS15810@dastard> <553EEB36.4080200@xxxxxxxxxxx> <5541253D.4090701@xxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, Apr 29, 2015 at 01:38:53PM -0500, Eric Sandeen wrote:
> On 4/27/15 9:06 PM, Eric Sandeen wrote:
> > On 4/27/15 8:20 PM, Dave Chinner wrote:
> > 
> >> I think that labels are a far better way of dealing with this
> >> problem. Get rid of the UUID mount checking (and hence the nouuid
> >> mount option), and tell people to use by-label instead of by-uuid to
> >> identify their filesystems when doing clones and snapshots. Labels
> >> make it much easier for humans to identify the filesystem than
> >> UUIDs...
> > 
> > I suppose so.  Withdrawn.  ;)
> One more thought.  ;)
> It'd be quite possible to keep defaults compatible with old kernels,
> and only set the new feature if/when a user requests a UUID change.
> If UUID changes are rare, it'll rarely matter; if they are required,
> it'll be possible.  I might send a patch just to make the discussion
> a bit more concrete.

Yes, we have precedence for doing things like that - v2 inodes,
attr2, etc. See what you come up with ;)


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>