public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Linda Walsh <xfs@tlinx.org>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH 0/2 V3] allow UUID changes on V5/CRC filesystems
Date: Wed, 03 Jun 2015 15:31:34 -0500	[thread overview]
Message-ID: <556F6426.5010002@sandeen.net> (raw)
In-Reply-To: <556EE18A.1080606@tlinx.org>

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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

      reply	other threads:[~2015-06-03 20:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-12 19:24 [PATCH 0/2 V3] allow UUID changes on V5/CRC filesystems Eric Sandeen
2015-05-12 19:27 ` [PATCH 1/2] xfs: create new metadata UUID field and incompat flag Eric Sandeen
2015-05-14 13:36   ` Brian Foster
2015-05-14 22:36   ` Dave Chinner
2015-05-14 22:55   ` [PATCH 1/2 V4] " Eric Sandeen
2015-05-12 19:30 ` [PATCH 2/2] xfsprogs: Add new sb_meta_uuid field, update userspace tools to manipulate it Eric Sandeen
2015-05-14 13:39   ` Brian Foster
2015-05-14 16:29     ` Eric Sandeen
2015-05-14 21:54   ` [PATCH 2/2 V4] " Eric Sandeen
2015-05-14 23:00     ` [PATCH 2/2 V5] " Eric Sandeen
2015-05-18 14:35       ` Brian Foster
2015-06-03 11:14 ` [PATCH 0/2 V3] allow UUID changes on V5/CRC filesystems Linda Walsh
2015-06-03 20:31   ` Eric Sandeen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=556F6426.5010002@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.com \
    --cc=xfs@tlinx.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox