xfs
[Top] [All Lists]

Re: [PATCH 0/2 V3] allow UUID changes on V5/CRC filesystems

To: Linda Walsh <xfs@xxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
Subject: Re: [PATCH 0/2 V3] allow UUID changes on V5/CRC filesystems
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Wed, 03 Jun 2015 15:31:34 -0500
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <556EE18A.1080606@xxxxxxxxx>
References: <55525356.1020807@xxxxxxxxxxx> <556EE18A.1080606@xxxxxxxxx>
On 6/3/15 6:14 AM, Linda Walsh wrote:
> 
> 
> Eric Sandeen wrote:
>> Final version?  This has been through some degree of testing, by changing
>> the UUID after a CRC mkfs, and re-setting it in between two xfs_repair runs
>> before and after each test in the testsuite.
> ---
>     I think I see my problem.

Oh?  what's that?  ;)

>     Is there some strong technical reason why 'crc' has to be on to get 
> -finobt=1 && ftype=1.  I'd like to try the latter two
> features, but the 'crc' stuff has me a bit bugged -- for unanticipated
> reasons like not being able to set the UUID (I so very often hit
> those corner cases...*lucky-me*).

mkfs.xfs -n ftype=1 will get you ftype w/ no crcs.

But some of the above requirements are just because we can't have an infinite 
test matrix.  

Look at ext4 - would you like a flex_bg filesystem with bigalloc? what about a 
no-extents, meta-bg nodelalloc filesystem?  Maybe a 64bit, no-resize-inode ... 
you get the picture.  There are some very dark corners in a test matrix like 
that.

So the decision was made that for most new features, they were going to depend 
on the latest rev of the disk format, to keep the xfs code, developers, and 
users all relatively sane.   Relatively...

-Eric

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