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

DISCUSSION L.A. Walsh 3 participants 12 messages Aug 7, 2015 – Aug 13, 2015

Share & tools

L.A. Walsh

author

2015-08-07 02:52 UTC #0 lore raw

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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Eric Sandeen

2015-08-07 05:00 UTC #1 lore raw

Quoted 3 lines · 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?

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

Quoted 1 line

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.

Quoted 6 lines

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.

Quoted 4 lines

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

Quoted 8 lines

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

Quoted 1 line

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

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

Quoted 11 lines

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?

Quoted 9 lines

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

Quoted 7 lines

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

Quoted 1 line

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?

Quoted 6 lines

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.

Quoted 5 lines

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

Quoted 3 lines

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

Quoted 10 lines

Thanks much!
L. Walsh
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

L.A. Walsh

author

2015-08-07 08:14 UTC #2 lore raw

Quoted 6 lines · Eric Sandeen

Quoted 2 lines · 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?
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.

Quoted 2 lines

Quoted 2 lines
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.

Quoted 8 lines

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.

Quoted 14 lines

Quoted 5 lines
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
Quoted 8 lines
       =                       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

Quoted 6 lines

ok...
Quoted 1 line
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.

Quoted 4 lines

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)

Quoted 1 line

not following.

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

Quoted 4 lines

Quoted 2 lines
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:

Quoted 1 line

sudo mount /home2

mount: mount /dev/mapper/Data-Home2 on /home2 failed: Structure needs cleaning

Quoted 2 lines

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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Eric Sandeen

2015-08-07 17:02 UTC #3 lore raw

Quoted 11 lines · L.A. Walsh

Quoted 6 lines · Eric Sandeen
Quoted 2 lines · 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?
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.

...

Quoted 6 lines

Quoted 3 lines
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.

Quoted 15 lines

Quoted 15 lines
Quoted 14 lines
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

Quoted 7 lines

Quoted 6 lines
ok...
Quoted 1 line
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.

Quoted 14 lines

---
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.
Quoted 4 lines
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?

Quoted 5 lines

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)

Quoted 2 lines

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

Quoted 7 lines

Quoted 3 lines
Quoted 1 line
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:
Quoted 1 line
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Dave Chinner

2015-08-07 22:55 UTC #4 lore raw

In reply to L.A. Walsh

Quoted 14 lines · L.A. Walsh

Quoted 14 lines · L.A. Walsh
Quoted 12 lines
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

Quoted 8 lines

Quoted 6 lines
ok...
Quoted 1 line
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.

Signature · 7 lines

Dave Chinner
[email protected]

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

L.A. Walsh

author

2015-08-08 00:50 UTC #5 lore raw

Quoted 4 lines · Dave Chinner

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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Eric Sandeen

2015-08-08 01:45 UTC #6 lore raw

Quoted 8 lines · L.A. Walsh

Dave Chinner wrote:

Quoted 8 lines

Quoted 4 lines
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

Quoted 1 line

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

L.A. Walsh

author

2015-08-08 02:59 UTC #7 lore raw

Quoted 4 lines · Eric Sandeen

Quoted 3 lines · L.A. Walsh
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Dave Chinner

2015-08-09 00:13 UTC #8 lore raw

Quoted 11 lines · L.A. Walsh

Quoted 4 lines · Eric Sandeen
Quoted 3 lines · L.A. Walsh
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.

Signature · 7 lines

Dave Chinner
[email protected]

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

L.A. Walsh

author

2015-08-13 00:24 UTC #9 lore raw

In reply to Dave Chinner

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

Quoted 3 lines · Dave Chinner

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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

L.A. Walsh

author

2015-08-07 08:18 UTC #10 lore raw

In reply to Eric Sandeen

Quoted 3 lines · Eric Sandeen

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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Eric Sandeen

2015-08-07 05:36 UTC #11 lore raw

In reply to L.A. Walsh

Quoted 3 lines · 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?

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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs