why crc req on free-inobt & file-type-indir options?
L.A. Walsh
xfs at tlinx.org
Fri Aug 7 03:14:40 CDT 2015
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.
More information about the xfs
mailing list