Which xfsprogs version to which kernel version

Which xfsprogs version to which kernel version

[aluno3]

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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Which xfsprogs version to which kernel version

[Emmanuel Florac]

Le Thu, 26 Nov 2015 11:21:45 +0100
"aluno3@poczta.onet.pl" <aluno3@poczta.onet.pl> écrivait:

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

-- 
------------------------------------------------------------------------
Emmanuel Florac     |   Direction technique
                    |   Intellique
                    |	<eflorac@intellique.com>
                    |   +33 1 78 94 84 02
------------------------------------------------------------------------

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

Re: Which xfsprogs version to which kernel version

[aluno3]

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

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.

On 11/26/15 13:26, Emmanuel Florac wrote:
> Le Thu, 26 Nov 2015 11:21:45 +0100
> "aluno3@poczta.onet.pl" <aluno3@poczta.onet.pl> écrivait:
> 
>> 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.
> 

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

Re: Which xfsprogs version to which kernel version

[Brian Foster]

On Thu, Nov 26, 2015 at 02:18:51PM +0100, aluno3@poczta.onet.pl 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

> 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.
> 
> On 11/26/15 13:26, Emmanuel Florac wrote:
> > Le Thu, 26 Nov 2015 11:21:45 +0100
> > "aluno3@poczta.onet.pl" <aluno3@poczta.onet.pl> écrivait:
> > 
> >> 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.
> > 
> 
> _______________________________________________
> 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: Which xfsprogs version to which kernel version

[aluno3]

dmesg when mounting volume which was formated xfsprogs 4.3.0:

*
root@192.168.176.24:~$ mkfs.xfs -V
mkfs.xfs version 4.3.0

root@192.168.176.24:~$ 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

root@192.168.176.24:~$ 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.

root@192.168.176.24:~$ 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.
*

On 11/26/15 14:50, Brian Foster wrote:
> On Thu, Nov 26, 2015 at 02:18:51PM +0100, aluno3@poczta.onet.pl 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
> 
>> 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.
>>
>> On 11/26/15 13:26, Emmanuel Florac wrote:
>>> Le Thu, 26 Nov 2015 11:21:45 +0100
>>> "aluno3@poczta.onet.pl" <aluno3@poczta.onet.pl> écrivait:
>>>
>>>> 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.
>>>
>>
>> _______________________________________________
>> 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: Which xfsprogs version to which kernel version

[Brian Foster]

On Thu, Nov 26, 2015 at 03:36:58PM +0100, aluno3@poczta.onet.pl wrote:
> dmesg when mounting volume which was formated xfsprogs 4.3.0:
> 
> *
> root@192.168.176.24:~$ mkfs.xfs -V
> mkfs.xfs version 4.3.0
> 
> root@192.168.176.24:~$ 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
> 
> root@192.168.176.24:~$ 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.
> 
> root@192.168.176.24:~$ 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

> [  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.
> *
> 
> On 11/26/15 14:50, Brian Foster wrote:
> > On Thu, Nov 26, 2015 at 02:18:51PM +0100, aluno3@poczta.onet.pl 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
> > 
> >> 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.
> >>
> >> On 11/26/15 13:26, Emmanuel Florac wrote:
> >>> Le Thu, 26 Nov 2015 11:21:45 +0100
> >>> "aluno3@poczta.onet.pl" <aluno3@poczta.onet.pl> écrivait:
> >>>
> >>>> 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.
> >>>
> >>
> >> _______________________________________________
> >> 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

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

Re: Which xfsprogs version to which kernel version

[aluno3]

On 11/27/15 16:22, Brian Foster wrote:
> On Thu, Nov 26, 2015 at 03:36:58PM +0100, aluno3@poczta.onet.pl wrote:
>> dmesg when mounting volume which was formated xfsprogs 4.3.0:
>>
>> *
>> root@192.168.176.24:~$ mkfs.xfs -V
>> mkfs.xfs version 4.3.0
>>
>> root@192.168.176.24:~$ 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
>>
>> root@192.168.176.24:~$ 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.
>>
>> root@192.168.176.24:~$ 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>
> 

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

so is it safe to use xfsprogs 4.3.0 with crc=0 and ftype=0 with kernel
3.10?

> Brian
> 
>> [  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.
>> *
>>
>> On 11/26/15 14:50, Brian Foster wrote:
>>> On Thu, Nov 26, 2015 at 02:18:51PM +0100, aluno3@poczta.onet.pl 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
>>>
>>>> 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.
>>>>
>>>> On 11/26/15 13:26, Emmanuel Florac wrote:
>>>>> Le Thu, 26 Nov 2015 11:21:45 +0100
>>>>> "aluno3@poczta.onet.pl" <aluno3@poczta.onet.pl> écrivait:
>>>>>
>>>>>> 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.
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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

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

Re: Which xfsprogs version to which kernel version

[Carlos Maiolino]

On Mon, Nov 30, 2015 at 09:37:46AM +0100, aluno3@poczta.onet.pl wrote:
> On 11/27/15 16:22, Brian Foster wrote:
> > On Thu, Nov 26, 2015 at 03:36:58PM +0100, aluno3@poczta.onet.pl wrote:
> >> dmesg when mounting volume which was formated xfsprogs 4.3.0:
> >>
> >> *
> >> root@192.168.176.24:~$ mkfs.xfs -V
> >> mkfs.xfs version 4.3.0
> >>
> >> root@192.168.176.24:~$ 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
> >>
> >> root@192.168.176.24:~$ 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.
> >>
> >> root@192.168.176.24:~$ 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>
> > 
> 
> 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
> 
> 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.

> > Brian
> > 
> >> [  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.
> >> *
> >>
> >> On 11/26/15 14:50, Brian Foster wrote:
> >>> On Thu, Nov 26, 2015 at 02:18:51PM +0100, aluno3@poczta.onet.pl 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
> >>>
> >>>> 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.
> >>>>
> >>>> On 11/26/15 13:26, Emmanuel Florac wrote:
> >>>>> Le Thu, 26 Nov 2015 11:21:45 +0100
> >>>>> "aluno3@poczta.onet.pl" <aluno3@poczta.onet.pl> écrivait:
> >>>>>
> >>>>>> 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.
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

-- 
Carlos

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

Re: Which xfsprogs version to which kernel version

[Dave Chinner]

On Thu, Nov 26, 2015 at 11:21:45AM +0100, aluno3@poczta.onet.pl 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.
-- 
Dave Chinner
david@fromorbit.com

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

Re: Which xfsprogs version to which kernel version

[Martin Steigerwald]

Am Dienstag, 1. Dezember 2015, 08:41:04 CET schrieb Dave Chinner:
> On Thu, Nov 26, 2015 at 11:21:45AM +0100, aluno3@poczta.onet.pl 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.

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

> 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,
-- 
Martin

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

Re: Which xfsprogs version to which kernel version

[Dave Chinner]

On Tue, Dec 01, 2015 at 09:30:00AM +0100, Martin Steigerwald wrote:
> Am Dienstag, 1. Dezember 2015, 08:41:04 CET schrieb Dave Chinner:
> > On Thu, Nov 26, 2015 at 11:21:45AM +0100, aluno3@poczta.onet.pl 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.
> 
> 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.

> 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.
-- 
Dave Chinner
david@fromorbit.com

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

Re: Which xfsprogs version to which kernel version

[Eric Sandeen]

On 12/1/15 2:26 PM, Dave Chinner wrote:
> On Tue, Dec 01, 2015 at 09:30:00AM +0100, Martin Steigerwald wrote:
>> Am Dienstag, 1. Dezember 2015, 08:41:04 CET schrieb Dave Chinner:
>>> On Thu, Nov 26, 2015 at 11:21:45AM +0100, aluno3@poczta.onet.pl 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.
>>
>> 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.  ;)
 
> 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.
> 
>> 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

> 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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Which xfsprogs version to which kernel version

[Arkadiusz Miśkiewicz]

On Wednesday 02 of December 2015, Eric Sandeen wrote:
 
> >> 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.

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

> -Eric

-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

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

Re: Which xfsprogs version to which kernel version

[Dave Chinner]

On Wed, Dec 02, 2015 at 06:07:47PM +0100, Arkadiusz Miśkiewicz wrote:
> On Wednesday 02 of December 2015, Eric Sandeen wrote:
>  
> > >> 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.

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.
-- 
Dave Chinner
david@fromorbit.com

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

Re: Which xfsprogs version to which kernel version

[Eric Sandeen]

On 12/2/15 11:07 AM, Arkadiusz Miśkiewicz wrote:
>>>> 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.

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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs