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

["L.A. Walsh" <xfs@tlinx.org>]

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