why crc req on free-inobt & file-type-indir options?

why crc req on free-inobt & file-type-indir options?

[L.A. Walsh]

Could anyone point me at the discussion or literature as to why
a free-inodeB-Tree and inline-types, should *REQUIRE* a -crc=1 option?

Ultimately isn't it about the users/customers and what they will want?

I not saying to not make it a default -- but to require it to try
the other features? 

Main reason I asked, is I have had disks get partly corrupted meta data
before, and it looks like the crc information just says "this disk
has errors, so assume ALL is LOST!  Seems like one bit flip out of
a 32+Tb(4TB) are not great odds.

Example:
sudo mkfs-xfs-raid SCR /dev/mapper/Data-Home2
mkfs.xfs -mcrc=1,finobt=1 -i maxpct=5,size=512 -l 
size=32752b,lazy-count=1 -d su=64k,sw=4  -s size=4096 -L SCR -f 
/dev/mapper/Data-Home2
meta-data=/dev/mapper/Data-Home2 isize=512    agcount=32, 
agsize=12582896 blks
        =                       sectsz=4096  attr=2, projid32bit=1
        =                       crc=1        finobt=1
data     =                       bsize=4096   blocks=402652672, imaxpct=5
        =                       sunit=16     swidth=64 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=32752, version=2
        =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
xfs_admin: WARNING - filesystem uses v1 dirs,limited functionality provided.
cache_node_purge: refcount was 1, not zero (node=0x891ea0)
xfs_admin: cannot read root inode (117)
cache_node_purge: refcount was 1, not zero (node=0x894410)
xfs_admin: cannot read realtime bitmap inode (117)
xfs_admin: WARNING - filesystem uses v1 dirs,limited functionality provided.
Clearing log and setting UUID
writing all SBs
bad sb version # 0xbda5 in AG 0
failed to set UUID in AG 0
new UUID = 55c29a43-19b6-ba02-2015-08051620352b
26.34sec 0.11usr 14.97sys (57.28% cpu)
Ishtar:law/bin> time sudo mkfs-xfs-raid SCR /dev/mapper/Data-Home2
mkfs.xfs  -i maxpct=5,size=512 -l size=32752b,lazy-count=1 -d 
su=64k,sw=4  -s size=4096 -L SCR -f /dev/mapper/Data-Home2
meta-data=/dev/mapper/Data-Home2 isize=512    agcount=32, 
agsize=12582896 blks
        =                       sectsz=4096  attr=2, projid32bit=1
        =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=402652672, imaxpct=5
        =                       sunit=16     swidth=64 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal log           bsize=4096   blocks=32752, version=2
        =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
Clearing log and setting UUID
writing all SBs55
new UUID = 55c29acd-2ce9-d15a-2015-08051622534b
In case you were curious why  ^^date^^:time^^^?? gives me an idea of
how long a disk  (or partition) has been in service....


I don't see any benefit in something that fails the disk that quickly.
While I've heard a patch for the GUID is in the input stream -- that's
one thing.  If I go in and a bit-error has reduced my disk to v1-dirs
as a side effect, it sounds like the potential for damage is far greater
than with that option turned on.  Sure it may make you **aware** of a
potential problem more quickly (or a new SW error), but I didn't see
how it helped repair the disk when it was at fault. 

Also, is it my imagination or is mkfs.xfs taking longer, occasionally
alot longer -- on the order of >60 seconds  at long end vs ~30 at
lower endd.  It sorta felt like a drop cache was being done before
the real long one but the memusage didn't change. at
least part of the time.   Has anyone done any benchmarks both
ways on meta-data intensive workloads (I guess lots of mkdirs,
touch, rm, adding large ACL's) ...?


Thanks much!
L. Walsh


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

why crc req on free-inobt & file-type-indir options?

[L.A. Walsh]

Could anyone point me at the discussion or literature as to why
a free-inodeB-Tree and inline-types, should *REQUIRE* a -crc=1 option?

Ultimately isn't it about the users/customers and what they will want?

I not saying to not make it a default -- but to require it to try
the other features? 

Main reason I asked, is I have had disks get partly corrupted meta data
before, and it looks like the crc information just says "this disk
has errors, so assume ALL is LOST!  Seems like one bit flip out of
a 32+Tb(4TB) are not great odds.

Example:
sudo mkfs-xfs-raid SCR /dev/mapper/Data-Home2
mkfs.xfs -mcrc=1,finobt=1 -i maxpct=5,size=512 -l 
size=32752b,lazy-count=1 -d su=64k,sw=4  -s size=4096 -L SCR -f 
/dev/mapper/Data-Home2
meta-data=/dev/mapper/Data-Home2 isize=512    agcount=32, 
agsize=12582896 blks
        =                       sectsz=4096  attr=2, projid32bit=1
        =                       crc=1        finobt=1
data     =                       bsize=4096   blocks=402652672, imaxpct=5
        =                       sunit=16     swidth=64 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=32752, version=2
        =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
xfs_admin: WARNING - filesystem uses v1 dirs,limited functionality provided.
cache_node_purge: refcount was 1, not zero (node=0x891ea0)
xfs_admin: cannot read root inode (117)
cache_node_purge: refcount was 1, not zero (node=0x894410)
xfs_admin: cannot read realtime bitmap inode (117)
xfs_admin: WARNING - filesystem uses v1 dirs,limited functionality provided.
Clearing log and setting UUID
writing all SBs
bad sb version # 0xbda5 in AG 0
failed to set UUID in AG 0
new UUID = 55c29a43-19b6-ba02-2015-08051620352b
26.34sec 0.11usr 14.97sys (57.28% cpu)
Ishtar:law/bin> time sudo mkfs-xfs-raid SCR /dev/mapper/Data-Home2
mkfs.xfs  -i maxpct=5,size=512 -l size=32752b,lazy-count=1 -d 
su=64k,sw=4  -s size=4096 -L SCR -f /dev/mapper/Data-Home2
meta-data=/dev/mapper/Data-Home2 isize=512    agcount=32, 
agsize=12582896 blks
        =                       sectsz=4096  attr=2, projid32bit=1
        =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=402652672, imaxpct=5
        =                       sunit=16     swidth=64 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal log           bsize=4096   blocks=32752, version=2
        =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
Clearing log and setting UUID
writing all SBs55
new UUID = 55c29acd-2ce9-d15a-2015-08051622534b
In case you were curious why  ^^date^^:time^^^?? gives me an idea of
how long a disk  (or partition) has been in service....


I don't see any benefit in something that fails the disk that quickly.
While I've heard a patch for the GUID is in the input stream -- that's
one thing.  If I go in and a bit-error has reduced my disk to v1-dirs
as a side effect, it sounds like the potential for damage is far greater
than with that option turned on.  Sure it may make you **aware** of a
potential problem more quickly (or a new SW error), but I didn't see
how it helped repair the disk when it was at fault. 

Also, is it my imagination or is mkfs.xfs taking longer, occasionally
alot longer -- on the order of >60 seconds  at long end vs ~30 at
lower endd.  It sorta felt like a drop cache was being done before
the real long one but the memusage didn't change. at
least part of the time.   Has anyone done any benchmarks both
ways on meta-data intensive workloads (I guess lots of mkdirs,
touch, rm, adding large ACL's) ...?


Thanks much!
L. Walsh


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

Re: why crc req on free-inobt & file-type-indir options?

[Eric Sandeen]

On 8/6/15 7:52 PM, L.A. Walsh wrote:
> 
> Could anyone point me at the discussion or literature as to why
> a free-inodeB-Tree and inline-types, should *REQUIRE* a -crc=1 option?

In part, to limit the test matrix to something the small handful of
developers can fully support you on.

> Ultimately isn't it about the users/customers and what they will want?

Well, no, not necessarily.  Users want a lot of things.  It's as much about
what is possible, as it is about what is wished for.

> I not saying to not make it a default -- but to require it to try
> the other features?
> Main reason I asked, is I have had disks get partly corrupted meta data
> before, and it looks like the crc information just says "this disk
> has errors, so assume ALL is LOST!  Seems like one bit flip out of
> a 32+Tb(4TB) are not great odds.

I don't follow ... one bit flip on a filesystem will not cause the
filesystem to be lost.

> Example:
> sudo mkfs-xfs-raid SCR /dev/mapper/Data-Home2
> mkfs.xfs -mcrc=1,finobt=1 -i maxpct=5,size=512 -l size=32752b,lazy-count=1 -d su=64k,sw=4  -s size=4096 -L SCR -f /dev/mapper/Data-Home2
> meta-data=/dev/mapper/Data-Home2 isize=512    agcount=32, agsize=12582896 blks
>        =                       sectsz=4096  attr=2, projid32bit=1
>        =                       crc=1        finobt=1
> data     =                       bsize=4096   blocks=402652672, imaxpct=5
>        =                       sunit=16     swidth=64 blks
> naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
> log      =internal log           bsize=4096   blocks=32752, version=2
>        =                       sectsz=4096  sunit=1 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0

ok...

> xfs_admin: WARNING - filesystem uses v1 dirs,limited functionality provided.

Um, what?  What xfs_admin command generated this?  With what xfsprogs version?

> cache_node_purge: refcount was 1, not zero (node=0x891ea0)
> xfs_admin: cannot read root inode (117)
> cache_node_purge: refcount was 1, not zero (node=0x894410)
> xfs_admin: cannot read realtime bitmap inode (117)
> xfs_admin: WARNING - filesystem uses v1 dirs,limited functionality provided.
> Clearing log and setting UUID
> writing all SBs
> bad sb version # 0xbda5 in AG 0
> failed to set UUID in AG 0
> new UUID = 55c29a43-19b6-ba02-2015-08051620352b
> 26.34sec 0.11usr 14.97sys (57.28% cpu)

Something has gone wrong here, but you have not provided enough info for
us to know what it is.  Full sequence of commands, please, and xfsprogs
version number.  Is it just a bug?

> Ishtar:law/bin> time sudo mkfs-xfs-raid SCR /dev/mapper/Data-Home2
> mkfs.xfs  -i maxpct=5,size=512 -l size=32752b,lazy-count=1 -d su=64k,sw=4  -s size=4096 -L SCR -f /dev/mapper/Data-Home2
> meta-data=/dev/mapper/Data-Home2 isize=512    agcount=32, agsize=12582896 blks
>        =                       sectsz=4096  attr=2, projid32bit=1
>        =                       crc=0        finobt=0
> data     =                       bsize=4096   blocks=402652672, imaxpct=5
>        =                       sunit=16     swidth=64 blks
> naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
> log      =internal log           bsize=4096   blocks=32752, version=2
>        =                       sectsz=4096  sunit=1 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> Clearing log and setting UUID
> writing all SBs55
> new UUID = 55c29acd-2ce9-d15a-2015-08051622534b
> In case you were curious why  ^^date^^:time^^^?? gives me an idea of
> how long a disk  (or partition) has been in service....

not following.

> I don't see any benefit in something that fails the disk that quickly.

I'm sorry, I'm still not following.  What's failing here?

> While I've heard a patch for the GUID is in the input stream -- that's
> one thing.  If I go in and a bit-error has reduced my disk to v1-dirs
> as a side effect, it sounds like the potential for damage is far greater
> than with that option turned on.  Sure it may make you **aware** of a
> potential problem more quickly (or a new SW error), but I didn't see
> how it helped repair the disk when it was at fault.

Well ... *was* your disk at fault?  I can't tell how you arrived at the
scenario above.

but you're right, CRCs are more about early error detection than
enhanced error recovery.

> Also, is it my imagination or is mkfs.xfs taking longer, occasionally
> alot longer -- on the order of >60 seconds  at long end vs ~30 at
> lower endd.  It sorta felt like a drop cache was being done before
> the real long one but the memusage didn't change. at
> least part of the time.

I've not experienced that...

> Has anyone done any benchmarks both
> ways on meta-data intensive workloads (I guess lots of mkdirs,
> touch, rm, adding large ACL's) ...?

Both which ways?  With and without CRCs?  Yes, Dave did a lot of that
during development, IIRC.

-Eric

> 
> Thanks much!
> L. Walsh
> 
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

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

Re: why crc req on free-inobt & file-type-indir options?

[Eric Sandeen]

On 8/6/15 7:52 PM, L.A. Walsh wrote:
> 
> Could anyone point me at the discussion or literature as to why
> a free-inodeB-Tree and inline-types, should *REQUIRE* a -crc=1 option?

FWIW, you can enable ftype w/o crcs.  Today it's a little broken, if you
specify in the wrong order it fails.  I just sent a patch for that.

-Eric

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

Re: why crc req on free-inobt & file-type-indir options?

[L.A. Walsh]

Eric Sandeen wrote:
> On 8/6/15 7:52 PM, L.A. Walsh wrote:
>> Could anyone point me at the discussion or literature as to why
>> a free-inodeB-Tree and inline-types, should *REQUIRE* a -crc=1 option?
> 
> In part, to limit the test matrix to something the small handful of
> developers can fully support you on.
---
	That's actually a good reason to make disabling it an option.
If a problem comes up it is one more thing that can be disabled.  _theoretically_,
as I understand it, it _should_ be an option that is *mostly* orthogonal to other
options -- yes, if you try to *enable* it (if dynamic-enabling was even 
available, which it is not AFAIK), on something that wasn't crc'd, it
be expected to give many errors.


> 
>> Ultimately isn't it about the users/customers and what they will want?
----
	Seems like providing an off switch for your M5 unit would be a
reasonable idea if not forward thinking.  Ultimately, I wouldn't mind seeing
it **if**, it could limp along until a xfx_crc_repair could be done on the
device. .. allowing normal function to continue with appropriate warnings
about, shutting down that partition ASAP.  


> 
> Well, no, not necessarily.  Users want a lot of things.  It's as much about
> what is possible, as it is about what is wished for.
> 

> 
> I don't follow ... one bit flip on a filesystem will not cause the
> filesystem to be lost. 
----
Just twitching 1 bit in the guid would cause it to not compare and give messages like
the below.

 
> 
>> Example:
>> sudo mkfs-xfs-raid SCR /dev/mapper/Data-Home2
>> mkfs.xfs -mcrc=1,finobt=1 -i maxpct=5,size=512 -l size=32752b,lazy-count=1 -d su=64k,sw=4  -s size=4096 -L SCR -f /dev/mapper/Data-Home2
>> meta-data=/dev/mapper/Data-Home2 isize=512    agcount=32, agsize=12582896 blks
>>        =                       sectsz=4096  attr=2, projid32bit=1
>>        =                       crc=1        finobt=1
>> data     =                       bsize=4096   blocks=402652672, imaxpct=5
>>        =                       sunit=16     swidth=64 blks
>> naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
>> log      =internal log           bsize=4096   blocks=32752, version=2
>>        =                       sectsz=4096  sunit=1 blks, lazy-count=1
>> realtime =none                   extsz=4096   blocks=0, rtextents=0
> 
> ok...
> 
>> xfs_admin: WARNING - filesystem uses v1 dirs,limited functionality provided.
> 
> Um, what?  What xfs_admin command generated this?  With what xfsprogs version?
> /usr/sbin/xfs_admin -V
xfs_admin version 3.1.11
---
after the  mkfs.xfs:
cmd="mkfs.xfs $iops $lops $dops ${sector_size:+-s size=$sector_size} -L $lab -f $dev"
printf -- "%s\n" "$cmd"
$cmd && 
  xfs_admin -U $(/root/bin/gen-dateguid) $dev

the gen-dateguid -- just generates the guid.

> 
> Something has gone wrong here, but you have not provided enough info for
> us to know what it is.  Full sequence of commands, please, and xfsprogs
> version number.  Is it just a bug?


Full sequence = what you ...oops... the ops aren't expanded ... minor 
scripting dysfunction....hold on...

This is the working case:
time sudo  ./mkfs-xfs-raid SCR /dev/Data/Home2
mkfs.xfs  -i maxpct=5,size=512 -l size=32752b,lazy-count=1 -d su=64k,sw=4  -s size=4096 -L SCR -f /dev/Data/Home2
meta-data=/dev/Data/Home2        isize=512    agcount=32, agsize=12582896 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=402652672, imaxpct=5
         =                       sunit=16     swidth=64 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal log           bsize=4096   blocks=32752, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
Clearing log and setting UUID
writing all SBs
new UUID = 55c466ec-0447-d5f8-2015-080701060407
26.37sec 0.10usr 15.43sys (58.89% cpu)
---non working:
time sudo finobt=1 crc=1 ./mkfs-xfs-raid SCR /dev/Data/Home2    
mkfs.xfs -m crc=1,finobt=1 -i maxpct=5,size=512 -l size=32752b,lazy-count=1 -d su=64k,sw=4  -s size=4096 -L SCR -f /dev/Data/Home2
meta-data=/dev/Data/Home2        isize=512    agcount=32, agsize=12582896 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1
data     =                       bsize=4096   blocks=402652672, imaxpct=5
         =                       sunit=16     swidth=64 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=32752, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
xfs_admin: WARNING - filesystem uses v1 dirs,limited functionality provided.
cache_node_purge: refcount was 1, not zero (node=0x891ea0)
xfs_admin: cannot read root inode (117)
cache_node_purge: refcount was 1, not zero (node=0x894410)
xfs_admin: cannot read realtime bitmap inode (117)
xfs_admin: WARNING - filesystem uses v1 dirs,limited functionality provided.
Clearing log and setting UUID
writing all SBs
bad sb version # 0xbda5 in AG 0
failed to set UUID in AG 0
new UUID = 55c46721-1baa-6de0-2015-08070106572e
31.93sec 0.11usr 15.52sys (48.96% cpu)

> not following.
doesn't matter ... just telling you why I used guid


> 
>> I don't see any benefit in something that fails the disk that quickly.
> 
> I'm sorry, I'm still not following.  What's failing here?
----
The disk doesn't get made -- it is corrupted:
> sudo mount /home2
mount: mount /dev/mapper/Data-Home2 on /home2 failed: Structure needs cleaning

> Well ... *was* your disk at fault?  I can't tell how you arrived at the
> scenario above.
---
Explained any better?  w/crc and finobt, & set guid, I get unusable disk.
w/o those options, it's fine.

BTW -- the CRC's are stronger on 4k-sector disks -- they can recover
from more errors than the 512byte sector disks (or so disk lit says, as
they save enough space in concatenating 8 sectors, that they can use 
stronger ECC to correct more cases.




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

Re: why crc req on free-inobt & file-type-indir options?

[L.A. Walsh]

Eric Sandeen wrote: 
> Something has gone wrong here, but you have not provided enough info for
> us to know what it is.  Full sequence of commands, please, and xfsprogs
> version number.  Is it just a bug?
BTW -- kernel=4.1.0 (sorry -- left that out)

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

Re: why crc req on free-inobt & file-type-indir options?

[Eric Sandeen]

On 8/7/15 1:14 AM, L.A. Walsh wrote:
> 
> 
> Eric Sandeen wrote:
>> On 8/6/15 7:52 PM, L.A. Walsh wrote:
>>> Could anyone point me at the discussion or literature as to why
>>> a free-inodeB-Tree and inline-types, should *REQUIRE* a -crc=1 option?
>>
>> In part, to limit the test matrix to something the small handful of
>> developers can fully support you on.
> ---
>     That's actually a good reason to make disabling it an option.

Not from a test matrix POV.  If V5 superblocks have features A, B, and C,
that's one thing to test.   If you allow all 3 to be independent, now you
have 8 scenarios to test.  Well - more like *we* have 8 scenarios to test.

...

>>
>> I don't follow ... one bit flip on a filesystem will not cause the
>> filesystem to be lost. 
> ----
> Just twitching 1 bit in the guid would cause it to not compare and give messages like
> the below.

Ok, but the filesystem is not "lost."  It just needs to be repaired after
corruption.
 
> 
>>
>>> Example:
>>> sudo mkfs-xfs-raid SCR /dev/mapper/Data-Home2
>>> mkfs.xfs -mcrc=1,finobt=1 -i maxpct=5,size=512 -l size=32752b,lazy-count=1 -d su=64k,sw=4  -s size=4096 -L SCR -f /dev/mapper/Data-Home2
>>> meta-data=/dev/mapper/Data-Home2 isize=512    agcount=32, agsize=12582896 blks
>>>        =                       sectsz=4096  attr=2, projid32bit=1
>>>        =                       crc=1        finobt=1
>>> data     =                       bsize=4096   blocks=402652672, imaxpct=5
>>>        =                       sunit=16     swidth=64 blks
>>> naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
>>> log      =internal log           bsize=4096   blocks=32752, version=2
>>>        =                       sectsz=4096  sunit=1 blks, lazy-count=1
>>> realtime =none                   extsz=4096   blocks=0, rtextents=0
>>
>> ok...
>>
>>> xfs_admin: WARNING - filesystem uses v1 dirs,limited functionality provided.
>>
>> Um, what?  What xfs_admin command generated this?  With what xfsprogs version?
>> /usr/sbin/xfs_admin -V
> xfs_admin version 3.1.11

Over 2 years old, from May 2013... :(

You've hit an old bug, not a design feature; it was patched up with:

609f6bb xfs_db: disallow sb UUID write on v5 filesystems

and changing the UUID has only recently become possible, and will be available
in the next release.

So, yes, that xfs_db bug let you create a mismatch which shouldn't have been allowed,
and caused corruption.  But the more relevant question is, could xfs_repair fix it?

You're right, this "one bit flip" caused it to be unmountable.  But all XFS knows
is that the superblock has been corrupted, and the CRC is now wrong, so it stops and
lets you take a look, and fix things as appropriate.

> ---
> after the  mkfs.xfs:
> cmd="mkfs.xfs $iops $lops $dops ${sector_size:+-s size=$sector_size} -L $lab -f $dev"
> printf -- "%s\n" "$cmd"
> $cmd &&  xfs_admin -U $(/root/bin/gen-dateguid) $dev
> 
> the gen-dateguid -- just generates the guid.
> 
>>
>> Something has gone wrong here, but you have not provided enough info for
>> us to know what it is.  Full sequence of commands, please, and xfsprogs
>> version number.  Is it just a bug?
> 
> 
> Full sequence = what you ...oops... the ops aren't expanded ... minor scripting dysfunction....hold on...
> 
> This is the working case:
> time sudo  ./mkfs-xfs-raid SCR /dev/Data/Home2
> mkfs.xfs  -i maxpct=5,size=512 -l size=32752b,lazy-count=1 -d su=64k,sw=4  -s size=4096 -L SCR -f /dev/Data/Home2

(right, non-crc filesystems can always handle UUID changes)

> ---non working:
> time sudo finobt=1 crc=1 ./mkfs-xfs-raid SCR /dev/Data/Home2    mkfs.xfs -m crc=1,finobt=1 -i maxpct=5,size=512 -l size=32752b,lazy-count=1 -d su=64k,sw=4  -s size=4096 -L SCR -f /dev/Data/Home2

(right, until very recently, crc filesystems could not change UUIDs,
but a bug allowed xfs_db to do it anyway, and corrupt the CRC)

>>> I don't see any benefit in something that fails the disk that quickly.
>>
>> I'm sorry, I'm still not following.  What's failing here?
> ----
> The disk doesn't get made -- it is corrupted:
>> sudo mount /home2
> mount: mount /dev/mapper/Data-Home2 on /home2 failed: Structure needs cleaning

dmesg should tell you in detail what's wrong.
and xfs_repair should be able to fix it.

But yes, this is a bug (fixed last April) that incorrectly allowed xfs_admin/xfs_db
to modify the UUID on a CRC filesystem, causing corruption.

-Eric

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

Re: why crc req on free-inobt & file-type-indir options?

[Dave Chinner]

On Fri, Aug 07, 2015 at 01:14:40AM -0700, L.A. Walsh wrote:
> >On 8/6/15 7:52 PM, L.A. Walsh wrote:
> >>Example:
> >>sudo mkfs-xfs-raid SCR /dev/mapper/Data-Home2
> >>mkfs.xfs -mcrc=1,finobt=1 -i maxpct=5,size=512 -l size=32752b,lazy-count=1 -d su=64k,sw=4  -s size=4096 -L SCR -f /dev/mapper/Data-Home2
> >>meta-data=/dev/mapper/Data-Home2 isize=512    agcount=32, agsize=12582896 blks
> >>       =                       sectsz=4096  attr=2, projid32bit=1
> >>       =                       crc=1        finobt=1
> >>data     =                       bsize=4096   blocks=402652672, imaxpct=5
> >>       =                       sunit=16     swidth=64 blks
> >>naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
> >>log      =internal log           bsize=4096   blocks=32752, version=2
> >>       =                       sectsz=4096  sunit=1 blks, lazy-count=1
> >>realtime =none                   extsz=4096   blocks=0, rtextents=0
> >
> >ok...
> >
> >>xfs_admin: WARNING - filesystem uses v1 dirs,limited functionality provided.
> >
> >Um, what?  What xfs_admin command generated this?  With what xfsprogs version?
> >/usr/sbin/xfs_admin -V
> xfs_admin version 3.1.11
> ---

The above error message is what old versions of xfs_db emit when
they see a filesystem version they don't understand.

xfsprogs 3.1.11 doesn't support CRCs. 3.2.0 was the first version of
xfsprogs to support CRCs, and 3.2.1 (IIRC) was the first to support
finobt, so the make binary came from a different build to the xfs_db
binary that xfs_admin executes.

Can you please ensure that you are running an up-to-date xfsprogs
and not some mix-and-match of different versions with differing
feature support capabilities?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: why crc req on free-inobt & file-type-indir options?

[L.A. Walsh]

Dave Chinner wrote:

> xfsprogs 3.1.11 doesn't support CRCs. 3.2.0 was the first version of
> xfsprogs to support CRCs, and 3.2.1 (IIRC) was the first to support
> finobt, so the make binary came from a different build to the xfs_db
> binary that xfs_admin executes.
----
I'll have to do some research on this.

Q: should the versions of xfsdump&restore be the same as 
the rest of the xfsprogs?





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

Re: why crc req on free-inobt & file-type-indir options?

[Eric Sandeen]

> On Aug 7, 2015, at 5:50 PM, L.A. Walsh <xfs@tlinx.org> wrote:
> 
> 
> 
> Dave Chinner wrote:
> 
>> xfsprogs 3.1.11 doesn't support CRCs. 3.2.0 was the first version of
>> xfsprogs to support CRCs, and 3.2.1 (IIRC) was the first to support
>> finobt, so the make binary came from a different build to the xfs_db
>> binary that xfs_admin executes.
> ----
> I'll have to do some research on this.
> 
> Q: should the versions of xfsdump&restore be the same as the rest of the xfsprogs?
Nope, they are separate packages with separate versioning.

-Eric

> 

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

Re: why crc req on free-inobt & file-type-indir options?

[L.A. Walsh]

Eric Sandeen wrote:
> 
>> On Aug 7, 2015, at 5:50 PM, L.A. Walsh <xfs@tlinx.org> wrote:
>> Q: should the versions of xfsdump&restore be the same as the rest of the xfsprogs?
> Nope, they are separate packages with separate versioning.
---
I see.  So how does one tell which version of xfsdump/restore should
be used to "safely" dump (and restore) a file system made
with version i.j.k of xfsprogs(mkfs.xfs) ?  Or is that possible?


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

Re: why crc req on free-inobt & file-type-indir options?

[Dave Chinner]

On Fri, Aug 07, 2015 at 07:59:43PM -0700, L.A. Walsh wrote:
> 
> 
> Eric Sandeen wrote:
> >
> >>On Aug 7, 2015, at 5:50 PM, L.A. Walsh <xfs@tlinx.org> wrote:
> >>Q: should the versions of xfsdump&restore be the same as the rest of the xfsprogs?
> >Nope, they are separate packages with separate versioning.
> ---
> I see.  So how does one tell which version of xfsdump/restore should
> be used to "safely" dump (and restore) a file system made
> with version i.j.k of xfsprogs(mkfs.xfs) ?  Or is that possible?

xfsdump does not care what version of the XFS filesystem it operates
on as it does not access the raw on-disk srtuctures. i.e.
xfsdump/restore are just like any other userspace application that
uses standard syscalls and ioctls to read/write information to/from
the filesystem.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: why crc req on free-inobt & file-type-indir options?

[L.A. Walsh]

(re: timelag: It took me a few revisions to get this out..)

Dave Chinner wrote:
> Can you please ensure that you are running an up-to-date xfsprogs
> and not some mix-and-match of different versions with differing
> feature support capabilities?
----
	Will the latest version allow me to specify 
finobt=1, ftype=1  && projid32bit=0 with crc=1?

	I'm pretty sure I don't have a version of xfs_admin that
disallows setting the GUID in the presence of a mkfs.xfs that does.

	As to how they would get mismatched, I have "/" on a different
partition from "/usr" (among others).  My distro has been moving files
from "/" -> /usr  primarily the  bin & lib dirs.  xfs_admin in their
setup was in /usr/sbin/ before this "move", while mkfs.xfs was in /sbin
(along with xfs_repair and fsck.xfs).  They have been "supporting the 
old paths by moving the binaries under /usr, while putting symlinks
from progs like "/bin/mount" -> "/usr/bin/mount".  On systems like mine,
that would result in system that boots but can't mount any other file
systems.  So wrote script that detected "mount order", and dereferenced
unsafe symlinks that pointed to file systems later in the mount order.

	Since the xfsprogs were split, and I hadn't gotten around to
inspecting date-stamps on binaries (I *did* manage to do version checks
on libraries, as mount's libraries were moved to /usr/lib64 before
mount was -- so the /bin/mount wouldn't load w/o /usr mounted.

	There's also the fact that I've tried to keep the mkfs & xfsrestore 
utils on the rootfs -- since that's allowed me to recover/restore
/usr and /var partitions that have gone belly up, but backups and such
aren't that important to most people, it seems.

	Also, needless to say, suse couldn't move from /usr to "/", because
"/" is now on device /dev/rootfs, so programs and users won't easily know 
when they are running in a "container" or "virtualized" root.  Anyway,
this move has caused a few headaches and not just to me.  


As for the 'crc' option:


	I wouldn't mind having the 'crc option being a default'
just as 'recovery' and 'uuid' are default -- I.e. allow mounting
a crc-fs w/o crc checks -- so a known bad disk can still have data
recovered from it.  It seems the ability to make a file system with
crc=0 while other options (finobt ftype) can be on would be a 
pre-rerequisite for allowing that at *mount* time (in addition to
mkfs time).

I use norecovery, to mount 'temporary'  snapshots as I
know, the logs may be out-of-sync with the contents, but for
my purposes that's never been a problem. 

Since it seems that 'ftype' is headed toward crc-independence, 
and finobt (I think) is hoped to be more efficient for free space
allocation, -- just how much metadata is normally associated with
free space (i.e. normally I think of time/date/access/ext_attrs
as metadata)?

	I keep trying to keep my xfs-repair and restore utils
on my rootfs (whether it has /usr on it or not), since, more than
once I've been able to restore a /usr or /var from the rootfs alone.


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