| To: | Dave Chinner <david@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: Proposal/RFC: new metadata-specific UUID for V5 supers |
| From: | Eric Sandeen <sandeen@xxxxxxxxxxx> |
| Date: | Wed, 29 Apr 2015 13:38:53 -0500 |
| Cc: | xfs-oss <xfs@xxxxxxxxxxx> |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <553EEB36.4080200@xxxxxxxxxxx> |
| References: | <553EB3D1.10602@xxxxxxxxxxx> <20150427233754.GT21261@dastard> <553ED9D8.4050106@xxxxxxxxxxx> <20150428012003.GS15810@dastard> <553EEB36.4080200@xxxxxxxxxxx> |
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. Thanks, -Eric |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Inode and dentry cache behavior, Shrinand Javadekar |
|---|---|
| Next by Date: | Re: Proposal/RFC: new metadata-specific UUID for V5 supers, Dave Chinner |
| Previous by Thread: | Re: Proposal/RFC: new metadata-specific UUID for V5 supers, Eric Sandeen |
| Next by Thread: | Re: Proposal/RFC: new metadata-specific UUID for V5 supers, Dave Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |