public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthias Schniedermeyer <ms@citd.de>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: V5 format and man mkfs.xfs
Date: Tue, 17 Jun 2014 17:29:17 +0200	[thread overview]
Message-ID: <20140617152917.GA17378@citd.de> (raw)
In-Reply-To: <20140617123738.GH9508@dastard>

On 17.06.2014 22:37, Dave Chinner wrote:
> On Tue, Jun 17, 2014 at 10:26:51AM +0200, Matthias Schniedermeyer wrote:
> > Hi
> > 
> > How seriously meant is "V5 isn't experimental anymore"?
> 
> "Fully supported" isn't a clear enough statement?

I guess that was a "selective memory"-bug on my side.

> > I ask because the man-page only mentions the syntax to enable it by 
> > accident. A.k.a. the backport of ftype to V4.
> > (man-page of xfsprogs 3.2.0 in Debian-SID)
> 
> That's intentional. V5 superblocks are an implementation detail that
> most users don't even need to know about. They care about the name
> of the features they are enabling at mkfs time, not the details of
> the on-disk implementation of those features.

The question still stands.

The crc-option is only mentioned "by accident".
Without the ftype backport there would be no mention of the "feature 
crc".

Furthermore i suspect that the ftype-feature also wouldn't be mentionted 
without the V4 backport.

Which beggs the question, what other features are "burried" in V5 that 
aren't mentioned in the man-page.

And are there any other "-m" options, because "-m" (asside from the 
ftype accident) is completly undocumented.

> > And you still have to know that crc means V5.
> 
> Why do you care about the format mkfs.xfs chooses for you - it's
> based on the features you requested. V5 isn't magically faster than

I find the crc feature relativly important.

I personally had exprienced an USB enclosure(-model. As in i had several 
of those) that under rare circumstances flipped or cleared a single bit 
in a specific bit-pattern). Such corruption most likely ends up inside a 
data-file because most times there is more data than meta-data. But 
COULD happend inside the meta-data.

Since that day i have nearly everything MD5(or SHA256)ed so i can at 
least detect if i have a data-corruption.

Fortunatly that never happend again after i replaced that enclosure 
model. Which i can say with pretty high confidence.

> V4 - there are many cases where it is slower due to CRC overhead
> or the overhead of the larger inode it requires. So unless you
> request a feature that requires it at mkfs time, you don't get that
> format.

Are there any feature besides crc/ftype in V5?

But i guess for "-n type=1" i would get a V4 + feature_bit.

And "-m crc=1" chooses V5 and i get ftype as a bonus (If i understand 
correctly).

> In a year or so we'll change the mkfs default so that CRCs are
> enabled by default, but we can't do that until all the distro's have
> had time to pick up a kernel that fully supports the CRC feature....

OK. So V5 will be the future default.





-- 

Matthias

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

  reply	other threads:[~2014-06-17 15:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-17  8:26 V5 format and man mkfs.xfs Matthias Schniedermeyer
2014-06-17 12:37 ` Dave Chinner
2014-06-17 15:29   ` Matthias Schniedermeyer [this message]
2014-06-17 22:46     ` Dave Chinner
2014-06-18  3:39     ` Greg Freemyer

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=20140617152917.GA17378@citd.de \
    --to=ms@citd.de \
    --cc=david@fromorbit.com \
    --cc=xfs@oss.sgi.com \
    /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