V5 format and man mkfs.xfs

V5 format and man mkfs.xfs

[Matthias Schniedermeyer]

Hi



How seriously meant is "V5 isn't experimental anymore"?

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)

And you still have to know that crc means V5.




-- 

Matthias

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

Re: V5 format and man mkfs.xfs

[Dave Chinner]

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 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.

> 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
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.

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....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: V5 format and man mkfs.xfs

[Matthias Schniedermeyer]

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

Re: V5 format and man mkfs.xfs

[Dave Chinner]

On Tue, Jun 17, 2014 at 05:29:17PM +0200, Matthias Schniedermeyer wrote:
> 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".

Ok, so you're not reporting that we don't mention V5 filesystems as
"V5" filesystems. You're reporting that the "-m crc" option is not
documented. That's an oversight, and needs to be fixed.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: V5 format and man mkfs.xfs

[Greg Freemyer]

On June 17, 2014 11:29:17 AM EDT, Matthias Schniedermeyer <ms@citd.de> wrote:
>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.

I md5 hash a lot of important files.  I've seen lots of failures to verify over the years.  As you note, it is typically a hardware failure, but they happen none the less.

Recently the most common failure has been the sata cables.  They are not very robust if you connect/disconnect them very often.

Greg
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

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