Which xfsprogs version to which kernel version
Hello,
I am using kernel 3.10 and would like to update xfsprogs (currently I have 3.1.5).
When I tried to use the newest version of xfsprogs 4.3.0 I get the call trace about detected version 5 of superblock when mounting volume which was formatted using mkfs.xfs from 4.3.0.
[ 606.853643] XFS (zd32): Version 5 superblock detected. This kernel has EXPERIMENTAL support enabled! Use of these features in this kernel is at your own risk! [ 606.853649] XFS (zd32): Superblock has unknown read-only compatible features (0x1) enabled. [ 606.853651] XFS (zd32): Attempted to mount read-only compatible filesystem read-write. Filesystem can only be safely mounted read only. [ 606.853654] ffff880067a71000: 58 46 53 42 00 00 10 00 00 00 00 00 01 90 00 00 XFSB............ [ 606.853657] ffff880067a71010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 606.853658] ffff880067a71020: 63 d1 24 9f 21 3d 44 a0 8c 51 5b 4e 31 1a 70 1e c.$.!=D..Q[N1.p. [ 606.853660] ffff880067a71030: 00 00 00 00 01 00 00 05 00 00 00 00 00 00 00 60 ...............` [ 606.853663] XFS (zd32): Internal error xfs_sb_read_verify at line 730 of file fs/xfs/xfs_mount.c. Caller 0xffffffff81256c7d
[ 606.853667] CPU: 0 PID: 200 Comm: kworker/0:1H Tainted: P O 3.10.92-oe64-ge331686 #15 [ 606.853668] Hardware name: System manufacturer System Product Name/P5WDG2 WS Pro, BIOS 0905 03/06/2008 [ 606.853675] Workqueue: xfslogd xfs_buf_iodone_work [ 606.853677] ffffffff81692f75 ffffffff81258c5d ffffffff81256c7d ffffffff818a39e3 [ 606.853680] ffff88005dcab200 0000000000000016 ffff880052c11800 0000000000000200 [ 606.853683] ffff88007ea17800 ffffffff812a32ac ffffffff81256c7d 000000007ea11a40 [ 606.853686] Call Trace: [ 606.853692] [<ffffffff81692f75>] ? dump_stack+0xc/0x15 [ 606.853695] [<ffffffff81258c5d>] ? xfs_corruption_error+0x8d/0x90 [ 606.853698] [<ffffffff81256c7d>] ? xfs_buf_iodone_work+0x6d/0x90 [ 606.853703] [<ffffffff812a32ac>] ? xfs_sb_read_verify+0xfc/0x120 [ 606.853705] [<ffffffff81256c7d>] ? xfs_buf_iodone_work+0x6d/0x90 [ 606.853708] [<ffffffff81256c7d>] ? xfs_buf_iodone_work+0x6d/0x90 [ 606.853712] [<ffffffff8105ce4d>] ? process_one_work+0x13d/0x3b0 [ 606.853715] [<ffffffff8105d7b1>] ? worker_thread+0x121/0x3d0 [ 606.853717] [<ffffffff8105d690>] ? manage_workers.isra.26+0x280/0x280 [ 606.853721] [<ffffffff81062e92>] ? kthread+0xc2/0xd0 [ 606.853725] [<ffffffff81070000>] ? sched_clock_cpu+0x30/0x100 [ 606.853728] [<ffffffff81062dd0>] ? kthread_create_on_node+0x110/0x110 [ 606.853731] [<ffffffff8169db98>] ? ret_from_fork+0x58/0x90 [ 606.853734] [<ffffffff81062dd0>] ? kthread_create_on_node+0x110/0x110 [ 606.853736] XFS (zd32): Corruption detected. Unmount and run xfs_repair [ 606.853742] XFS (zd32): SB validate failed with error 22.
Dave in thread http://oss.sgi.com/archives/xfs/2015-08/msg00528.html
advises to disable crc and finobt:
mkfs.xfs -m crc=0,finobt=0
but it does not work with 4.X version of xfsprogs. Call trace also occurred so I tried to use 3.2.4 family with crc=0,finobt=0 and volume mounted successfully.
Dave also noticed:
i.e. if Gentoo are shipping xfsprogs 3.2.4 w/ kernel 3.14.51, then Gentoo has a quality control problem - they have failed to verify that the packages they are shipping work correctly before shipping them to users...
that using 3.2.4 with kernel 3.14.51 is not good idea so are you able to advise which version of xfsprogs is the best for kernel 3.10? Please note that update the kernel in my environment is not possible in easy way so I need to stay with 3.10.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Le Thu, 26 Nov 2015 11:21:45 +0100 "[email protected]" <[email protected]> écrivait:
Quoted 6 lines
mkfs.xfs -m crc=0,finobt=0
but it does not work with 4.X version of xfsprogs. Call trace also occurred so I tried to use 3.2.4 family with crc=0,finobt=0 and volume mounted successfully.
Did you use -f? else mkfs.xfs won't do anything as it'll detect an existing filesystem.
Signature · 11 lines
------------------------------------------------------------------------
Emmanuel Florac | Direction technique
| Intellique
| <[email protected]>
| +33 1 78 94 84 02
------------------------------------------------------------------------
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfsYes I used -f option with 4.X version of xfsprogs but mounting the volume was not possible - before mkfs.xfs finished successfully (mkfs.xfs -f -m crc=0,finobt=0).
Should I stay in 3.1.X family of xfsprogs or is it recommended to use at least 3.2.x version with kernel 3.10?
The most I care about xfs_repair.
Quoted 5 lines · Emmanuel Florac
Le Thu, 26 Nov 2015 11:21:45 +0100 "[email protected]" <[email protected]> écrivait:
Quoted 2 lines
mkfs.xfs -m crc=0,finobt=0
Quoted 8 lines
Quoted 4 lines
but it does not work with 4.X version of xfsprogs. Call trace also occurred so I tried to use 3.2.4 family with crc=0,finobt=0 and volume mounted successfully.
Did you use -f? else mkfs.xfs won't do anything as it'll detect an existing filesystem.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 4 lines · On Thu, Nov 26, 2015 at 02:18:51PM +0100, [email protected] wrote:
Yes I used -f option with 4.X version of xfsprogs but mounting the volume was not possible - before mkfs.xfs finished successfully (mkfs.xfs -f -m crc=0,finobt=0).
You posted the output associated with the crc=1 fs mount failure, what happens when you try to mount after formatting with crc=0?
Brian
Quoted 16 lines
Should I stay in 3.1.X family of xfsprogs or is it recommended to use at least 3.2.x version with kernel 3.10?
The most I care about
xfs_repair.Quoted 10 lines · Emmanuel Florac
Le Thu, 26 Nov 2015 11:21:45 +0100 "[email protected]" <[email protected]> écrivait:
Quoted 6 lines
mkfs.xfs -m crc=0,finobt=0
but it does not work with 4.X version of xfsprogs. Call trace also occurred so I tried to use 3.2.4 family with crc=0,finobt=0 and volume mounted successfully.
Quoted 8 lines
Quoted 3 lines
Did you use -f? else mkfs.xfs won't do anything as it'll detect an existing filesystem.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
dmesg when mounting volume which was formated xfsprogs 4.3.0:
*
[email protected]:~$ mkfs.xfs -V mkfs.xfs version 4.3.0
[email protected]:~$ mkfs.xfs -f -m crc=0,finobt=0 /dev/sdc4 meta-data=/dev/sdc4 isize=256 agcount=4, agsize=474552 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0, sparse=0 data = bsize=4096 blocks=1898208, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0
[email protected]:~$ mount /dev/sdc4 /mnt/sdc4 mount: wrong fs type, bad option, bad superblock on /dev/sdc4, missing codepage or helper program, or other error
In some cases useful info is found in syslog - try dmesg | tail or so.
[email protected]:~$ dmesg [ 212.984534] XFS (sdc4): bad version [ 212.984547] ffff88005cccb000: 58 46 53 42 00 00 10 00 00 00 00 00 00 1c f6 e0 XFSB............ [ 212.984550] ffff88005cccb010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 212.984551] ffff88005cccb020: 55 9d 20 d9 1c e9 4e a9 a3 ee 8d fd ba 68 b3 70 U. ...N......h.p [ 212.984553] ffff88005cccb030: 00 00 00 00 00 10 00 04 00 00 00 00 00 00 00 80 ................ [ 212.984556] XFS (sdc4): Internal error xfs_sb_read_verify at line 730 of file fs/xfs/xfs_mount.c. Caller 0xffffffff81256c7d
[ 212.984560] CPU: 0 PID: 440 Comm: kworker/0:1H Tainted: P O 3.10.92-oe64-ge331686 #15 [ 212.984562] Hardware name: System manufacturer System Product Name/P5WDG2 WS Pro, BIOS 0905 03/06/2008 [ 212.984567] Workqueue: xfslogd xfs_buf_iodone_work [ 212.984570] ffffffff81692f75 ffffffff81258c5d ffffffff81256c7d ffffffff818a39e3 [ 212.984573] ffff88007aa9ef00 0000000000000016 ffff88007aa8b000 0000000000000000 [ 212.984576] ffff88007ea17800 ffffffff812a32ac ffffffff81256c7d ffff88007ea11a40 [ 212.984579] Call Trace: [ 212.984584] [<ffffffff81692f75>] ? dump_stack+0xc/0x15 [ 212.984587] [<ffffffff81258c5d>] ? xfs_corruption_error+0x8d/0x90 [ 212.984590] [<ffffffff81256c7d>] ? xfs_buf_iodone_work+0x6d/0x90 [ 212.984595] [<ffffffff812a32ac>] ? xfs_sb_read_verify+0xfc/0x120 [ 212.984598] [<ffffffff81256c7d>] ? xfs_buf_iodone_work+0x6d/0x90 [ 212.984600] [<ffffffff81256c7d>] ? xfs_buf_iodone_work+0x6d/0x90 [ 212.984604] [<ffffffff8105ce4d>] ? process_one_work+0x13d/0x3b0 [ 212.984607] [<ffffffff8105d7b1>] ? worker_thread+0x121/0x3d0 [ 212.984609] [<ffffffff8105d690>] ? manage_workers.isra.26+0x280/0x280 [ 212.984613] [<ffffffff81062e92>] ? kthread+0xc2/0xd0 [ 212.984616] [<ffffffff81070000>] ? sched_clock_cpu+0x30/0x100 [ 212.984619] [<ffffffff81062dd0>] ? kthread_create_on_node+0x110/0x110 [ 212.984623] [<ffffffff8169db98>] ? ret_from_fork+0x58/0x90 [ 212.984626] [<ffffffff81062dd0>] ? kthread_create_on_node+0x110/0x110 [ 212.984628] XFS (sdc4): Corruption detected. Unmount and run xfs_repair [ 212.984634] XFS (sdc4): SB validate failed with error 22.
*
Quoted 6 lines · Brian Foster
Quoted 4 lines · On Thu, Nov 26, 2015 at 02:18:51PM +0100, [email protected] wrote:
Yes I used -f option with 4.X version of xfsprogs but mounting the volume was not possible - before mkfs.xfs finished successfully (mkfs.xfs -f -m crc=0,finobt=0).
Quoted 29 lines
You posted the output associated with the crc=1 fs mount failure, what happens when you try to mount after formatting with crc=0?
Brian
Quoted 24 lines
Should I stay in 3.1.X family of xfsprogs or is it recommended to use at least 3.2.x version with kernel 3.10?
The most I care about
xfs_repair.Quoted 5 lines · Emmanuel Florac
Le Thu, 26 Nov 2015 11:21:45 +0100 "[email protected]" <[email protected]> écrivait:
Quoted 2 lines
mkfs.xfs -m crc=0,finobt=0
Quoted 8 lines
Quoted 4 lines
but it does not work with 4.X version of xfsprogs. Call trace also occurred so I tried to use 3.2.4 family with crc=0,finobt=0 and volume mounted successfully.
Did you use -f? else mkfs.xfs won't do anything as it'll detect an existing filesystem.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 24 lines · On Thu, Nov 26, 2015 at 03:36:58PM +0100, [email protected] wrote:
dmesg when mounting volume which was formated xfsprogs 4.3.0:
*
[email protected]:~$ mkfs.xfs -V mkfs.xfs version 4.3.0[email protected]:~$ mkfs.xfs -f -m crc=0,finobt=0 /dev/sdc4 meta-data=/dev/sdc4 isize=256 agcount=4, agsize=474552 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0, sparse=0 data = bsize=4096 blocks=1898208, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0[email protected]:~$ mount /dev/sdc4 /mnt/sdc4 mount: wrong fs type, bad option, bad superblock on /dev/sdc4, missing codepage or helper program, or other errorIn some cases useful info is found in syslog - try dmesg | tail or so.
Quoted 13 lines
[email protected]:~$ dmesg [ 212.984534] XFS (sdc4): bad version [ 212.984547] ffff88005cccb000: 58 46 53 42 00 00 10 00 00 00 00 00 00 1c f6 e0 XFSB............ [ 212.984550] ffff88005cccb010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 212.984551] ffff88005cccb020: 55 9d 20 d9 1c e9 4e a9 a3 ee 8d fd ba 68 b3 70 U. ...N......h.p [ 212.984553] ffff88005cccb030: 00 00 00 00 00 10 00 04 00 00 00 00 00 00 00 80 ................ [ 212.984556] XFS (sdc4): Internal error xfs_sb_read_verify at line 730 of file fs/xfs/xfs_mount.c. Caller 0xffffffff81256c7d
Interesting... have you tried to format without ftype support? It looks like that wasn't introduced until v3.13. E.g.,
mkfs.xfs -f -m crc=0 -n ftype=0 <dev>
Brian
Quoted 67 lines
[ 212.984560] CPU: 0 PID: 440 Comm: kworker/0:1H Tainted: P O 3.10.92-oe64-ge331686 #15 [ 212.984562] Hardware name: System manufacturer System Product Name/P5WDG2 WS Pro, BIOS 0905 03/06/2008 [ 212.984567] Workqueue: xfslogd xfs_buf_iodone_work [ 212.984570] ffffffff81692f75 ffffffff81258c5d ffffffff81256c7d ffffffff818a39e3 [ 212.984573] ffff88007aa9ef00 0000000000000016 ffff88007aa8b000 0000000000000000 [ 212.984576] ffff88007ea17800 ffffffff812a32ac ffffffff81256c7d ffff88007ea11a40 [ 212.984579] Call Trace: [ 212.984584] [<ffffffff81692f75>] ? dump_stack+0xc/0x15 [ 212.984587] [<ffffffff81258c5d>] ? xfs_corruption_error+0x8d/0x90 [ 212.984590] [<ffffffff81256c7d>] ? xfs_buf_iodone_work+0x6d/0x90 [ 212.984595] [<ffffffff812a32ac>] ? xfs_sb_read_verify+0xfc/0x120 [ 212.984598] [<ffffffff81256c7d>] ? xfs_buf_iodone_work+0x6d/0x90 [ 212.984600] [<ffffffff81256c7d>] ? xfs_buf_iodone_work+0x6d/0x90 [ 212.984604] [<ffffffff8105ce4d>] ? process_one_work+0x13d/0x3b0 [ 212.984607] [<ffffffff8105d7b1>] ? worker_thread+0x121/0x3d0 [ 212.984609] [<ffffffff8105d690>] ? manage_workers.isra.26+0x280/0x280 [ 212.984613] [<ffffffff81062e92>] ? kthread+0xc2/0xd0 [ 212.984616] [<ffffffff81070000>] ? sched_clock_cpu+0x30/0x100 [ 212.984619] [<ffffffff81062dd0>] ? kthread_create_on_node+0x110/0x110 [ 212.984623] [<ffffffff8169db98>] ? ret_from_fork+0x58/0x90 [ 212.984626] [<ffffffff81062dd0>] ? kthread_create_on_node+0x110/0x110 [ 212.984628] XFS (sdc4): Corruption detected. Unmount and run xfs_repair [ 212.984634] XFS (sdc4): SB validate failed with error 22.*
Quoted 6 lines · Brian Foster
Quoted 4 lines · On Thu, Nov 26, 2015 at 02:18:51PM +0100, [email protected] wrote:
Yes I used -f option with 4.X version of xfsprogs but mounting the volume was not possible - before mkfs.xfs finished successfully (mkfs.xfs -f -m crc=0,finobt=0).
Quoted 29 lines
You posted the output associated with the crc=1 fs mount failure, what happens when you try to mount after formatting with crc=0?
Brian
Quoted 24 lines
Should I stay in 3.1.X family of xfsprogs or is it recommended to use at least 3.2.x version with kernel 3.10?
The most I care about
xfs_repair.Quoted 5 lines · Emmanuel Florac
Le Thu, 26 Nov 2015 11:21:45 +0100 "[email protected]" <[email protected]> écrivait:
Quoted 2 lines
mkfs.xfs -m crc=0,finobt=0
Quoted 8 lines
Quoted 4 lines
but it does not work with 4.X version of xfsprogs. Call trace also occurred so I tried to use 3.2.4 family with crc=0,finobt=0 and volume mounted successfully.
Did you use -f? else mkfs.xfs won't do anything as it'll detect an existing filesystem.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 4 lines
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 39 lines · Brian Foster
Quoted 24 lines · On Thu, Nov 26, 2015 at 03:36:58PM +0100, [email protected] wrote:
dmesg when mounting volume which was formated xfsprogs 4.3.0:
*
[email protected]:~$ mkfs.xfs -V mkfs.xfs version 4.3.0[email protected]:~$ mkfs.xfs -f -m crc=0,finobt=0 /dev/sdc4 meta-data=/dev/sdc4 isize=256 agcount=4, agsize=474552 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0, sparse=0 data = bsize=4096 blocks=1898208, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0[email protected]:~$ mount /dev/sdc4 /mnt/sdc4 mount: wrong fs type, bad option, bad superblock on /dev/sdc4, missing codepage or helper program, or other errorIn some cases useful info is found in syslog - try dmesg | tail or so.
Quoted 13 lines
[email protected]:~$ dmesg [ 212.984534] XFS (sdc4): bad version [ 212.984547] ffff88005cccb000: 58 46 53 42 00 00 10 00 00 00 00 00 00 1c f6 e0 XFSB............ [ 212.984550] ffff88005cccb010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 212.984551] ffff88005cccb020: 55 9d 20 d9 1c e9 4e a9 a3 ee 8d fd ba 68 b3 70 U. ...N......h.p [ 212.984553] ffff88005cccb030: 00 00 00 00 00 10 00 04 00 00 00 00 00 00 00 80 ................ [ 212.984556] XFS (sdc4): Internal error xfs_sb_read_verify at line 730 of file fs/xfs/xfs_mount.c. Caller 0xffffffff81256c7d
Quoted 5 lines
Interesting... have you tried to format without ftype support? It looks like that wasn't introduced until v3.13. E.g.,
mkfs.xfs -f -m crc=0 -n ftype=0 <dev>
With ftype=0 and crc=0 options, mounting the volume is possible.
root:~$ mkfs.xfs -f -m crc=0 -n ftype=0 /dev/sdc
meta-data=/dev/sdc isize=256 agcount=4, agsize=30524162
blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0, sparse=0
data = bsize=4096 blocks=122096646, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal log bsize=4096 blocks=59617, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
root:~$ mount /dev/sdc /mnt/sdc
root:~$ dmesg
[ 1761.805159] sdc: unknown partition table
[ 1768.928019] XFS (sdc): Mounting Filesystem
[ 1768.987660] XFS (sdc): Ending clean mountso is it safe to use xfsprogs 4.3.0 with crc=0 and ftype=0 with kernel 3.10?
Quoted 73 lines
Brian
Quoted 71 lines
[ 212.984560] CPU: 0 PID: 440 Comm: kworker/0:1H Tainted: P O 3.10.92-oe64-ge331686 #15 [ 212.984562] Hardware name: System manufacturer System Product Name/P5WDG2 WS Pro, BIOS 0905 03/06/2008 [ 212.984567] Workqueue: xfslogd xfs_buf_iodone_work [ 212.984570] ffffffff81692f75 ffffffff81258c5d ffffffff81256c7d ffffffff818a39e3 [ 212.984573] ffff88007aa9ef00 0000000000000016 ffff88007aa8b000 0000000000000000 [ 212.984576] ffff88007ea17800 ffffffff812a32ac ffffffff81256c7d ffff88007ea11a40 [ 212.984579] Call Trace: [ 212.984584] [<ffffffff81692f75>] ? dump_stack+0xc/0x15 [ 212.984587] [<ffffffff81258c5d>] ? xfs_corruption_error+0x8d/0x90 [ 212.984590] [<ffffffff81256c7d>] ? xfs_buf_iodone_work+0x6d/0x90 [ 212.984595] [<ffffffff812a32ac>] ? xfs_sb_read_verify+0xfc/0x120 [ 212.984598] [<ffffffff81256c7d>] ? xfs_buf_iodone_work+0x6d/0x90 [ 212.984600] [<ffffffff81256c7d>] ? xfs_buf_iodone_work+0x6d/0x90 [ 212.984604] [<ffffffff8105ce4d>] ? process_one_work+0x13d/0x3b0 [ 212.984607] [<ffffffff8105d7b1>] ? worker_thread+0x121/0x3d0 [ 212.984609] [<ffffffff8105d690>] ? manage_workers.isra.26+0x280/0x280 [ 212.984613] [<ffffffff81062e92>] ? kthread+0xc2/0xd0 [ 212.984616] [<ffffffff81070000>] ? sched_clock_cpu+0x30/0x100 [ 212.984619] [<ffffffff81062dd0>] ? kthread_create_on_node+0x110/0x110 [ 212.984623] [<ffffffff8169db98>] ? ret_from_fork+0x58/0x90 [ 212.984626] [<ffffffff81062dd0>] ? kthread_create_on_node+0x110/0x110 [ 212.984628] XFS (sdc4): Corruption detected. Unmount and run xfs_repair [ 212.984634] XFS (sdc4): SB validate failed with error 22.*
Quoted 6 lines · Brian Foster
Quoted 4 lines · On Thu, Nov 26, 2015 at 02:18:51PM +0100, [email protected] wrote:
Yes I used -f option with 4.X version of xfsprogs but mounting the volume was not possible - before mkfs.xfs finished successfully (mkfs.xfs -f -m crc=0,finobt=0).
Quoted 29 lines
You posted the output associated with the crc=1 fs mount failure, what happens when you try to mount after formatting with crc=0?
Brian
Quoted 24 lines
Should I stay in 3.1.X family of xfsprogs or is it recommended to use at least 3.2.x version with kernel 3.10?
The most I care about
xfs_repair.Quoted 5 lines · Emmanuel Florac
Le Thu, 26 Nov 2015 11:21:45 +0100 "[email protected]" <[email protected]> écrivait:
Quoted 2 lines
mkfs.xfs -m crc=0,finobt=0
Quoted 8 lines
Quoted 4 lines
but it does not work with 4.X version of xfsprogs. Call trace also occurred so I tried to use 3.2.4 family with crc=0,finobt=0 and volume mounted successfully.
Did you use -f? else mkfs.xfs won't do anything as it'll detect an existing filesystem.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 66 lines · On Mon, Nov 30, 2015 at 09:37:46AM +0100, [email protected] wrote:
Quoted 39 lines · Brian Foster
Quoted 24 lines · On Thu, Nov 26, 2015 at 03:36:58PM +0100, [email protected] wrote:
dmesg when mounting volume which was formated xfsprogs 4.3.0:
*
[email protected]:~$ mkfs.xfs -V mkfs.xfs version 4.3.0[email protected]:~$ mkfs.xfs -f -m crc=0,finobt=0 /dev/sdc4 meta-data=/dev/sdc4 isize=256 agcount=4, agsize=474552 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0, sparse=0 data = bsize=4096 blocks=1898208, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0[email protected]:~$ mount /dev/sdc4 /mnt/sdc4 mount: wrong fs type, bad option, bad superblock on /dev/sdc4, missing codepage or helper program, or other errorIn some cases useful info is found in syslog - try dmesg | tail or so.
Quoted 13 lines
[email protected]:~$ dmesg [ 212.984534] XFS (sdc4): bad version [ 212.984547] ffff88005cccb000: 58 46 53 42 00 00 10 00 00 00 00 00 00 1c f6 e0 XFSB............ [ 212.984550] ffff88005cccb010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 212.984551] ffff88005cccb020: 55 9d 20 d9 1c e9 4e a9 a3 ee 8d fd ba 68 b3 70 U. ...N......h.p [ 212.984553] ffff88005cccb030: 00 00 00 00 00 10 00 04 00 00 00 00 00 00 00 80 ................ [ 212.984556] XFS (sdc4): Internal error xfs_sb_read_verify at line 730 of file fs/xfs/xfs_mount.c. Caller 0xffffffff81256c7dQuoted 5 lines
Interesting... have you tried to format without ftype support? It looks like that wasn't introduced until v3.13. E.g.,
mkfs.xfs -f -m crc=0 -n ftype=0 <dev>With ftype=0 and crc=0 options, mounting the volume is possible.
root:~$ mkfs.xfs -f -m crc=0 -n ftype=0 /dev/sdc meta-data=/dev/sdc isize=256 agcount=4, agsize=30524162 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 finobt=0, sparse=0 data = bsize=4096 blocks=122096646, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal log bsize=4096 blocks=59617, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 root:~$ mount /dev/sdc /mnt/sdc root:~$ dmesg [ 1761.805159] sdc: unknown partition table [ 1768.928019] XFS (sdc): Mounting Filesystem [ 1768.987660] XFS (sdc): Ending clean mount
Quoted 3 lines
so is it safe to use xfsprogs 4.3.0 with crc=0 and ftype=0 with kernel 3.10?
Hi,
it's safe once you're disabling the unsupported filesystem formats for the kernel you're using.
Quoted 78 lines
Quoted 73 lines
Brian
Quoted 71 lines
[ 212.984560] CPU: 0 PID: 440 Comm: kworker/0:1H Tainted: P O 3.10.92-oe64-ge331686 #15 [ 212.984562] Hardware name: System manufacturer System Product Name/P5WDG2 WS Pro, BIOS 0905 03/06/2008 [ 212.984567] Workqueue: xfslogd xfs_buf_iodone_work [ 212.984570] ffffffff81692f75 ffffffff81258c5d ffffffff81256c7d ffffffff818a39e3 [ 212.984573] ffff88007aa9ef00 0000000000000016 ffff88007aa8b000 0000000000000000 [ 212.984576] ffff88007ea17800 ffffffff812a32ac ffffffff81256c7d ffff88007ea11a40 [ 212.984579] Call Trace: [ 212.984584] [<ffffffff81692f75>] ? dump_stack+0xc/0x15 [ 212.984587] [<ffffffff81258c5d>] ? xfs_corruption_error+0x8d/0x90 [ 212.984590] [<ffffffff81256c7d>] ? xfs_buf_iodone_work+0x6d/0x90 [ 212.984595] [<ffffffff812a32ac>] ? xfs_sb_read_verify+0xfc/0x120 [ 212.984598] [<ffffffff81256c7d>] ? xfs_buf_iodone_work+0x6d/0x90 [ 212.984600] [<ffffffff81256c7d>] ? xfs_buf_iodone_work+0x6d/0x90 [ 212.984604] [<ffffffff8105ce4d>] ? process_one_work+0x13d/0x3b0 [ 212.984607] [<ffffffff8105d7b1>] ? worker_thread+0x121/0x3d0 [ 212.984609] [<ffffffff8105d690>] ? manage_workers.isra.26+0x280/0x280 [ 212.984613] [<ffffffff81062e92>] ? kthread+0xc2/0xd0 [ 212.984616] [<ffffffff81070000>] ? sched_clock_cpu+0x30/0x100 [ 212.984619] [<ffffffff81062dd0>] ? kthread_create_on_node+0x110/0x110 [ 212.984623] [<ffffffff8169db98>] ? ret_from_fork+0x58/0x90 [ 212.984626] [<ffffffff81062dd0>] ? kthread_create_on_node+0x110/0x110 [ 212.984628] XFS (sdc4): Corruption detected. Unmount and run xfs_repair [ 212.984634] XFS (sdc4): SB validate failed with error 22.*
Quoted 6 lines · Brian Foster
Quoted 4 lines · On Thu, Nov 26, 2015 at 02:18:51PM +0100, [email protected] wrote:
Yes I used -f option with 4.X version of xfsprogs but mounting the volume was not possible - before mkfs.xfs finished successfully (mkfs.xfs -f -m crc=0,finobt=0).
Quoted 29 lines
You posted the output associated with the crc=1 fs mount failure, what happens when you try to mount after formatting with crc=0?
Brian
Quoted 24 lines
Should I stay in 3.1.X family of xfsprogs or is it recommended to use at least 3.2.x version with kernel 3.10?
The most I care about
xfs_repair.Quoted 5 lines · Emmanuel Florac
Le Thu, 26 Nov 2015 11:21:45 +0100 "[email protected]" <[email protected]> écrivait:
Quoted 2 lines
mkfs.xfs -m crc=0,finobt=0
Quoted 8 lines
Quoted 4 lines
but it does not work with 4.X version of xfsprogs. Call trace also occurred so I tried to use 3.2.4 family with crc=0,finobt=0 and volume mounted successfully.
Did you use -f? else mkfs.xfs won't do anything as it'll detect an existing filesystem.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Signature · 6 lines
Carlos _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 8 lines · On Thu, Nov 26, 2015 at 11:21:45AM +0100, [email protected] wrote:
Hello,
I am using kernel 3.10 and would like to update xfsprogs (currently I have 3.1.5).
When I tried to use the newest version of xfsprogs 4.3.0 I get the call trace about detected version 5 of superblock when mounting volume which was formatted using mkfs.xfs from 4.3.0.
More recent xfsprogs versions enable features that are only supported by recent kernels. We tend to wait at least a year before enabling new features by default in xfsprogs so that kernel support is usually picke dup by distros before they update xfsprogs....
If you have an old kernel, then you need to turn off the newer features that your kernel does not support. This has always been the case - if you update the xfsprogs yourself, then you need to use the correct options for your kernel. In general, this:
# mkfs.xfs -f -m crc=0 -n ftype=0 <dev>
will make a filesystem that can be mounted on old kernels. If distros are shipping old kernels with new xfsprogs and are not changing the default behaviour to suit their kernel, then that is a distro problem.
As it is, in future the version of xfsprogs will tell you what kernel has the same feature support. i.e. xfsprogs 4.2.0 has exactly the same code/feature support as kernel 4.2.0. Similarly for xfsprogs/kernel 4.3.0. However, this won't prevent the fact that xfsprogs 4.8.0 might enable features that kernel 4.3.0 does not know about - the only way to prevent that sort of problem is to never enable new features in mkfs.xfs, and that's not a viable solution.
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Am Dienstag, 1. Dezember 2015, 08:41:04 CET schrieb Dave Chinner:
Quoted 20 lines · On Thu, Nov 26, 2015 at 11:21:45AM +0100, [email protected] wrote:
Quoted 8 lines
Hello,
I am using kernel 3.10 and would like to update xfsprogs (currently I have 3.1.5).
When I tried to use the newest version of xfsprogs 4.3.0 I get the call trace about detected version 5 of superblock when mounting volume which was formatted using mkfs.xfs from 4.3.0.
More recent xfsprogs versions enable features that are only supported by recent kernels. We tend to wait at least a year before enabling new features by default in xfsprogs so that kernel support is usually picke dup by distros before they update xfsprogs....
If you have an old kernel, then you need to turn off the newer features that your kernel does not support. This has always been the case - if you update the xfsprogs yourself, then you need to use the correct options for your kernel. In general, this:
Quoted 6 lines
# mkfs.xfs -f -m crc=0 -n ftype=0 <dev>will make a filesystem that can be mounted on old kernels. If distros are shipping old kernels with new xfsprogs and are not changing the default behaviour to suit their kernel, then that is a distro problem.
How about just checking running kernel version before enabling this by default? Of course this doesn´t cover the case where one does mkfs.xfs from a newer live distro and wants to mount with an older installed distro then. It also makes sense to make it possible to override the default choice as it is implemented right now.
Alternatively it would be an option to display a warning if by default a feature is enabled that is not supported by the running kernel.
While this is some implementation effort, it may help to reduce questions on this mailing list. And as you see distro problem or not: People still ask here. :)
Quoted 7 lines
As it is, in future the version of xfsprogs will tell you what kernel has the same feature support. i.e. xfsprogs 4.2.0 has exactly the same code/feature support as kernel 4.2.0. Similarly for xfsprogs/kernel 4.3.0. However, this won't prevent the fact that xfsprogs 4.8.0 might enable features that kernel 4.3.0 does not know about - the only way to prevent that sort of problem is to never enable new features in mkfs.xfs, and that's not a viable solution.
Nice to know. That is how btrfs-tools is versioned as well meanwhile.
Thanks,
Signature · 6 lines
Martin _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 23 lines · Martin Steigerwald
Am Dienstag, 1. Dezember 2015, 08:41:04 CET schrieb Dave Chinner:
Quoted 22 lines · On Thu, Nov 26, 2015 at 11:21:45AM +0100, [email protected] wrote:
Quoted 8 lines
Hello,
I am using kernel 3.10 and would like to update xfsprogs (currently I have 3.1.5).
When I tried to use the newest version of xfsprogs 4.3.0 I get the call trace about detected version 5 of superblock when mounting volume which was formatted using mkfs.xfs from 4.3.0.
More recent xfsprogs versions enable features that are only supported by recent kernels. We tend to wait at least a year before enabling new features by default in xfsprogs so that kernel support is usually picke dup by distros before they update xfsprogs....
If you have an old kernel, then you need to turn off the newer features that your kernel does not support. This has always been the case - if you update the xfsprogs yourself, then you need to use the correct options for your kernel. In general, this:
# mkfs.xfs -f -m crc=0 -n ftype=0 <dev>
Quoted 7 lines
Quoted 4 lines
will make a filesystem that can be mounted on old kernels. If distros are shipping old kernels with new xfsprogs and are not changing the default behaviour to suit their kernel, then that is a distro problem.
How about just checking running kernel version before enabling this by default?
The btrfs solution? No thanks.
Apart from the fact I make filesystems that the kernel does not support all the time, xfstests does the same thing so that we can test that the kernel correctly rejects mounts of filesystems with features it doesn't support. And this fails when a distro installer or rescue distro has a different kernel to the one the distro actually uses, too...
And, really, where does this slipperly slope end? Suddenly we have to maintain a map of every feature in every mainline kernel, then every distro kernel that does backports (e.g. sles, rhel, etc) and we end up with something nobody can maintain or test.
Quoted 3 lines
While this is some implementation effort, it may help to reduce questions on this mailing list. And as you see distro problem or not: People still ask here. :)
The majority of distro's get it right the majority of the time - there's no point in turning everything upside down just to silence a very small vocal minority. i.e. It's only when users do their own package upgrades, or a distro screws up (like gentoo with shipping 3.2.4 on an old kernel) that users end up with a problem.
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 29 lines · Dave Chinner
Quoted 28 lines · Martin Steigerwald
Am Dienstag, 1. Dezember 2015, 08:41:04 CET schrieb Dave Chinner:
Quoted 26 lines · On Thu, Nov 26, 2015 at 11:21:45AM +0100, [email protected] wrote:
Quoted 8 lines
Hello,
I am using kernel 3.10 and would like to update xfsprogs (currently I have 3.1.5).
When I tried to use the newest version of xfsprogs 4.3.0 I get the call trace about detected version 5 of superblock when mounting volume which was formatted using mkfs.xfs from 4.3.0.
More recent xfsprogs versions enable features that are only supported by recent kernels. We tend to wait at least a year before enabling new features by default in xfsprogs so that kernel support is usually picke dup by distros before they update xfsprogs....
If you have an old kernel, then you need to turn off the newer features that your kernel does not support. This has always been the case - if you update the xfsprogs yourself, then you need to use the correct options for your kernel. In general, this:
# mkfs.xfs -f -m crc=0 -n ftype=0 <dev>will make a filesystem that can be mounted on old kernels. If distros are shipping old kernels with new xfsprogs and are not changing the default behaviour to suit their kernel, then that is a distro problem.
Quoted 4 lines
Quoted 2 lines
How about just checking running kernel version before enabling this by default?
The btrfs solution? No thanks.
Another option is to export features the running kernel can handle in sysfs & mkfs accordingly - but then somebody mkfs's under one kernel, boots another kernel, and gets different mkfs's, possibly fails to mount, etc... magically changing defaults is a nightmare. yeah, at some point you have to realize that you cannot save everyone from themselves. ;)
Quoted 7 lines
Apart from the fact I make filesystems that the kernel does not support all the time, xfstests does the same thing so that we can test that the kernel correctly rejects mounts of filesystems with features it doesn't support. And this fails when a distro installer or rescue distro has a different kernel to the one the distro actually uses, too...
Quoted 8 lines
And, really, where does this slipperly slope end? Suddenly we have to maintain a map of every feature in every mainline kernel, then every distro kernel that does backports (e.g. sles, rhel, etc) and we end up with something nobody can maintain or test.
Quoted 3 lines
While this is some implementation effort, it may help to reduce questions on this mailing list. And as you see distro problem or not: People still ask here. :)
Like Dave said - not very often at all.
-Eric
Quoted 10 lines
The majority of distro's get it right the majority of the time - there's no point in turning everything upside down just to silence a very small vocal minority. i.e. It's only when users do their own package upgrades, or a distro screws up (like gentoo with shipping 3.2.4 on an old kernel) that users end up with a problem.
Cheers,
Dave.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Eric Sandeen
Quoted 4 lines
Quoted 2 lines
How about just checking running kernel version before enabling this by default?
The btrfs solution? No thanks.
Another option is to export features the running kernel can handle in sysfs & mkfs accordingly - but then somebody mkfs's under one kernel, boots another kernel, and gets different mkfs's, possibly fails to mount, etc... magically changing defaults is a nightmare. yeah, at some point you have to realize that you cannot save everyone from themselves. ;)
Don't change default. Warn instead about mkfs using feature not supported by current kernel.
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
While this is some implementation effort, it may help to reduce questions on this mailing list. And as you see distro problem or not:
People still ask here. :)Like Dave said - not very often at all.
Had one complain about the problem on pld lists.
Quoted 1 line
-Eric
Signature · 6 lines
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 7 lines · Arkadiusz Miśkiewicz
Quoted 5 lines · Eric Sandeen
Quoted 4 lines
Quoted 2 lines
How about just checking running kernel version before enabling this by default?
The btrfs solution? No thanks.
Quoted 8 lines
Quoted 5 lines
Another option is to export features the running kernel can handle in sysfs & mkfs accordingly - but then somebody mkfs's under one kernel, boots another kernel, and gets different mkfs's, possibly fails to mount, etc... magically changing defaults is a nightmare. yeah, at some point you have to realize that you cannot save everyone from themselves. ;)
Don't change default. Warn instead about mkfs using feature not supported by current kernel.
That's just as bad - we'll get people complaining about mkfs warnings they don't care about. And we will also end up with people not turning on options they really should be using, like metadata CRCs....
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 6 lines · Arkadiusz Miśkiewicz
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
While this is some implementation effort, it may help to reduce
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
questions on this mailing list. And as you see distro problem or not:
People still ask here. :)Like Dave said - not very often at all.
Had one complain about the problem on pld lists.
does pld ship an xfsprogs which is ahead of their kernel?
Or did the user go off and grab something newer on their own, and run into this?
-Eric
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs