* How to use increased number of ACL entries? @ 2013-11-03 8:17 Kasparek Tomas 2013-11-04 0:39 ` Dave Chinner 0 siblings, 1 reply; 13+ messages in thread From: Kasparek Tomas @ 2013-11-03 8:17 UTC (permalink / raw) To: xfs [-- Attachment #1.1: Type: text/plain, Size: 914 bytes --] Hello, I'm trying to get more then 25 ACLs entries to work according to http://oss.sgi.com/pipermail/xfs/2013-May/026544.html . I'm running 3.10.x kernel which seems to contain these changes. I understand, that this is on-disk format change, so I expect to need new xfsprogs too. I tried the version from CentOS 6.4 (3.1.1) and one from git repo ( git://oss.sgi.com/xfs/cmds/xfsprogs), but still it fails to create more then 25 ACL entries (21 user defined). Is there something I'm still missing? Thanks -- Tomas Kasparek E-mail: kasparek@fit.vutbr.cz CVT FIT VUT Brno, L127 Web: http://www.fit.vutbr.cz/~kasparek Bozetechova 1, 612 66 Fax: +420 54114-1270 Brno, Czech Republic Phone: +420 54114-1220 jabber: tomas.kasparek@jabber.cz GPG: 2F1E 1AAF FD3B CFA3 1537 63BD DCBE 18FF A035 53BC May the command line live forever! [-- Attachment #1.2: Type: application/pgp-signature, Size: 196 bytes --] [-- Attachment #2: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to use increased number of ACL entries? 2013-11-03 8:17 How to use increased number of ACL entries? Kasparek Tomas @ 2013-11-04 0:39 ` Dave Chinner 2013-11-04 2:37 ` Eric Sandeen 0 siblings, 1 reply; 13+ messages in thread From: Dave Chinner @ 2013-11-04 0:39 UTC (permalink / raw) To: Kasparek Tomas; +Cc: xfs On Sun, Nov 03, 2013 at 09:17:04AM +0100, Kasparek Tomas wrote: > Hello, > > I'm trying to get more then 25 ACLs entries to work according to > http://oss.sgi.com/pipermail/xfs/2013-May/026544.html . I'm running 3.10.x > kernel which seems to contain these changes. I understand, that this is > on-disk format change, so I expect to need new xfsprogs too. I tried the > version from CentOS 6.4 (3.1.1) and one from git repo ( > git://oss.sgi.com/xfs/cmds/xfsprogs), but still it fails to create more then > 25 ACL entries (21 user defined). Is there something I'm still missing? You haven't told mkfs to change the on disk format to enable more than 25 ACLs. Only the version from git will do it, and your CentOS kernel will not support it. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to use increased number of ACL entries? 2013-11-04 0:39 ` Dave Chinner @ 2013-11-04 2:37 ` Eric Sandeen 2013-11-04 4:18 ` Michael L. Semon 0 siblings, 1 reply; 13+ messages in thread From: Eric Sandeen @ 2013-11-04 2:37 UTC (permalink / raw) To: Dave Chinner, Kasparek Tomas; +Cc: xfs On 11/3/13, 6:39 PM, Dave Chinner wrote: > On Sun, Nov 03, 2013 at 09:17:04AM +0100, Kasparek Tomas wrote: >> Hello, >> >> I'm trying to get more then 25 ACLs entries to work according to >> http://oss.sgi.com/pipermail/xfs/2013-May/026544.html . I'm running 3.10.x >> kernel which seems to contain these changes. I understand, that this is >> on-disk format change, so I expect to need new xfsprogs too. I tried the >> version from CentOS 6.4 (3.1.1) and one from git repo ( >> git://oss.sgi.com/xfs/cmds/xfsprogs), but still it fails to create more then >> 25 ACL entries (21 user defined). Is there something I'm still missing? > > You haven't told mkfs to change the on disk format to enable more > than 25 ACLs. Only the version from git will do it, and your CentOS > kernel will not support it. but the 3.10.x kernel you're running will IIRC; use "-m crc=1" on the mkfs.xfs commandline from a git mkfs.xfs. -Eric > Cheers, > > Dave. > _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to use increased number of ACL entries? 2013-11-04 2:37 ` Eric Sandeen @ 2013-11-04 4:18 ` Michael L. Semon 2013-11-04 4:35 ` Jeff Liu 2013-11-04 14:24 ` Eric Sandeen 0 siblings, 2 replies; 13+ messages in thread From: Michael L. Semon @ 2013-11-04 4:18 UTC (permalink / raw) To: Eric Sandeen, Dave Chinner, Kasparek Tomas; +Cc: xfs On 11/03/2013 09:37 PM, Eric Sandeen wrote: > On 11/3/13, 6:39 PM, Dave Chinner wrote: >> On Sun, Nov 03, 2013 at 09:17:04AM +0100, Kasparek Tomas wrote: >>> Hello, >>> >>> I'm trying to get more then 25 ACLs entries to work according to >>> http://oss.sgi.com/pipermail/xfs/2013-May/026544.html . I'm running 3.10.x >>> kernel which seems to contain these changes. I understand, that this is >>> on-disk format change, so I expect to need new xfsprogs too. I tried the >>> version from CentOS 6.4 (3.1.1) and one from git repo ( >>> git://oss.sgi.com/xfs/cmds/xfsprogs), but still it fails to create more then >>> 25 ACL entries (21 user defined). Is there something I'm still missing? >> >> You haven't told mkfs to change the on disk format to enable more >> than 25 ACLs. Only the version from git will do it, and your CentOS >> kernel will not support it. > > but the 3.10.x kernel you're running will IIRC; use "-m crc=1" on the mkfs.xfs > commandline from a git mkfs.xfs. > > -Eric > >> Cheers, >> >> Dave. Y'know, Eric, your best suggestions are always made when I'm working on a non-test PC that I don't really want to touch ;-) But anyway, (i686 Pentium 4, kernel 3.10.17)... git xfsprogs will make the filesystem in question: root@bpserver:/storage/devel/git-xfsprogs# mkfs/mkfs.xfs /dev/sdb3 mkfs.xfs: /dev/sdb3 appears to contain an existing filesystem (swap). mkfs.xfs: Use the -f option to force overwrite. root@bpserver:/storage/devel/git-xfsprogs# mkfs/mkfs.xfs -f -m crc=1 /dev/sdb3 meta-data=/dev/sdb3 isize=512 agcount=4, agsize=65536 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 data = bsize=4096 blocks=262144, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=12800, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 However, it should be dirent (ftype=1 in the above output) that keeps a vanilla 3.10.17 kernel from mounting the resulting filesystem: [438326.624667] XFS (sdb3): Version 5 superblock detected. This kernel has EXPERIMENTAL support enabled! [438326.624667] Use of these features in this kernel is at your own risk! [438326.624762] XFS (sdb3): Superblock has unknown incompatible features (0x1) enabled. [438326.624762] Filesystem can not be safely mounted by this kernel. [438326.624769] 8d76c000: 58 46 53 42 00 00 10 00 00 00 00 00 00 04 00 00 XFSB............ [438326.624833] 8d76c010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [438326.624897] 8d76c020: 60 b9 e2 ff 8f c5 41 f5 87 32 bc ea 7d 7b 8c 1b `.....A..2..}{.. [438326.624961] 8d76c030: 00 00 00 00 00 02 00 04 00 00 00 00 00 00 00 40 ...............@ [438326.625026] XFS (sdb3): Internal error xfs_sb_read_verify at line 730 of file fs/xfs/xfs_mount.c. Caller 0x81123144 [438326.625026] [438326.625108] CPU: 0 PID: 58 Comm: kworker/0:1H Not tainted 3.10.17 #2 [438326.625110] Hardware name: Dell Computer Corporation Dimension 3000 /0N6381, BIOS A02 11/08/2004 [438326.625119] Workqueue: xfslogd xfs_buf_iodone_work [438326.625123] a4b38400 a4b38400 bde73e90 813ab881 bde73eb4 81124b91 a4b38400 00000008 [438326.625130] 814593ac 813c5439 000002da 8145fee6 81123144 bde73ed4 81124bd6 8145fee6 [438326.625136] 000002da 81123144 954cf500 00000016 a4b38400 bde73f00 811693c4 8d76c000 [438326.625142] Call Trace: [438326.625151] [<813ab881>] dump_stack+0x16/0x18 [438326.625155] [<81124b91>] xfs_error_report+0x45/0x47 [438326.625160] [<81123144>] ? xfs_buf_iodone_work+0x52/0x67 [438326.625163] [<81124bd6>] xfs_corruption_error+0x43/0x5d [438326.625167] [<81123144>] ? xfs_buf_iodone_work+0x52/0x67 [438326.625173] [<811693c4>] xfs_sb_read_verify+0xd4/0xe5 [438326.625177] [<81123144>] ? xfs_buf_iodone_work+0x52/0x67 [438326.625181] [<81123144>] xfs_buf_iodone_work+0x52/0x67 [438326.625187] [<81038920>] process_one_work+0xd5/0x2eb [438326.625191] [<8103923c>] worker_thread+0xea/0x2f8 [438326.625196] [<81039152>] ? manage_workers.isra.37+0x21a/0x21a [438326.625200] [<8103d4c4>] kthread+0x8e/0x90 [438326.625207] [<813af737>] ret_from_kernel_thread+0x1b/0x28 [438326.625211] [<8103d436>] ? kthread_worker_fn+0xd3/0xd3 [438326.625214] XFS (sdb3): Corruption detected. Unmount and run xfs_repair [438326.625271] XFS (sdb3): SB validate failed with error 22. I don't know if the CentOS kernel has any extra patches that would enable this filesystem to be mounted. There might be a way to bisect or revert the git xfsprogs back before dirent and giving that a try. However, it seems best to start working with v5/CRC XFS starting with kernel 3.11. If my luck with recent AIO commits was better, I'd recommend 3.12 instead because that's the real correct answer, problems aside. Thanks! Michael _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to use increased number of ACL entries? 2013-11-04 4:18 ` Michael L. Semon @ 2013-11-04 4:35 ` Jeff Liu 2013-11-04 5:52 ` Michael L. Semon 2013-11-04 14:24 ` Eric Sandeen 1 sibling, 1 reply; 13+ messages in thread From: Jeff Liu @ 2013-11-04 4:35 UTC (permalink / raw) To: Michael L. Semon; +Cc: Kasparek Tomas, Eric Sandeen, xfs On 11/04/2013 12:18 PM, Michael L. Semon wrote: > On 11/03/2013 09:37 PM, Eric Sandeen wrote: >> On 11/3/13, 6:39 PM, Dave Chinner wrote: >>> On Sun, Nov 03, 2013 at 09:17:04AM +0100, Kasparek Tomas wrote: >>>> Hello, >>>> >>>> I'm trying to get more then 25 ACLs entries to work according to >>>> http://oss.sgi.com/pipermail/xfs/2013-May/026544.html . I'm running 3.10.x >>>> kernel which seems to contain these changes. I understand, that this is >>>> on-disk format change, so I expect to need new xfsprogs too. I tried the >>>> version from CentOS 6.4 (3.1.1) and one from git repo ( >>>> git://oss.sgi.com/xfs/cmds/xfsprogs), but still it fails to create more then >>>> 25 ACL entries (21 user defined). Is there something I'm still missing? >>> >>> You haven't told mkfs to change the on disk format to enable more >>> than 25 ACLs. Only the version from git will do it, and your CentOS >>> kernel will not support it. >> >> but the 3.10.x kernel you're running will IIRC; use "-m crc=1" on the mkfs.xfs >> commandline from a git mkfs.xfs. >> >> -Eric >> >>> Cheers, >>> >>> Dave. > > Y'know, Eric, your best suggestions are always made when I'm working on a > non-test PC that I don't really want to touch ;-) But anyway, (i686 Pentium > 4, kernel 3.10.17)... > > git xfsprogs will make the filesystem in question: > > root@bpserver:/storage/devel/git-xfsprogs# mkfs/mkfs.xfs /dev/sdb3 > mkfs.xfs: /dev/sdb3 appears to contain an existing filesystem (swap). > mkfs.xfs: Use the -f option to force overwrite. > root@bpserver:/storage/devel/git-xfsprogs# mkfs/mkfs.xfs -f -m crc=1 /dev/sdb3 > meta-data=/dev/sdb3 isize=512 agcount=4, agsize=65536 blks > = sectsz=512 attr=2, projid32bit=1 > = crc=1 > data = bsize=4096 blocks=262144, imaxpct=25 > = sunit=0 swidth=0 blks > naming =version 2 bsize=4096 ascii-ci=0 ftype=1 > log =internal log bsize=4096 blocks=12800, version=2 > = sectsz=512 sunit=0 blks, lazy-count=1 > realtime =none extsz=4096 blocks=0, rtextents=0 > > However, it should be dirent (ftype=1 in the above output) that keeps a > vanilla 3.10.17 kernel from mounting the resulting filesystem: > > [438326.624667] XFS (sdb3): Version 5 superblock detected. This kernel has EXPERIMENTAL support enabled! > [438326.624667] Use of these features in this kernel is at your own risk! > [438326.624762] XFS (sdb3): Superblock has unknown incompatible features (0x1) enabled. > [438326.624762] Filesystem can not be safely mounted by this kernel. > [438326.624769] 8d76c000: 58 46 53 42 00 00 10 00 00 00 00 00 00 04 00 00 XFSB............ > [438326.624833] 8d76c010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > [438326.624897] 8d76c020: 60 b9 e2 ff 8f c5 41 f5 87 32 bc ea 7d 7b 8c 1b `.....A..2..}{.. > [438326.624961] 8d76c030: 00 00 00 00 00 02 00 04 00 00 00 00 00 00 00 40 ...............@ > [438326.625026] XFS (sdb3): Internal error xfs_sb_read_verify at line 730 of file fs/xfs/xfs_mount.c. Caller 0x81123144 > [438326.625026] > [438326.625108] CPU: 0 PID: 58 Comm: kworker/0:1H Not tainted 3.10.17 #2 > [438326.625110] Hardware name: Dell Computer Corporation Dimension 3000 /0N6381, BIOS A02 11/08/2004 > [438326.625119] Workqueue: xfslogd xfs_buf_iodone_work > [438326.625123] a4b38400 a4b38400 bde73e90 813ab881 bde73eb4 81124b91 a4b38400 00000008 > [438326.625130] 814593ac 813c5439 000002da 8145fee6 81123144 bde73ed4 81124bd6 8145fee6 > [438326.625136] 000002da 81123144 954cf500 00000016 a4b38400 bde73f00 811693c4 8d76c000 > [438326.625142] Call Trace: > [438326.625151] [<813ab881>] dump_stack+0x16/0x18 > [438326.625155] [<81124b91>] xfs_error_report+0x45/0x47 > [438326.625160] [<81123144>] ? xfs_buf_iodone_work+0x52/0x67 > [438326.625163] [<81124bd6>] xfs_corruption_error+0x43/0x5d > [438326.625167] [<81123144>] ? xfs_buf_iodone_work+0x52/0x67 > [438326.625173] [<811693c4>] xfs_sb_read_verify+0xd4/0xe5 > [438326.625177] [<81123144>] ? xfs_buf_iodone_work+0x52/0x67 > [438326.625181] [<81123144>] xfs_buf_iodone_work+0x52/0x67 > [438326.625187] [<81038920>] process_one_work+0xd5/0x2eb > [438326.625191] [<8103923c>] worker_thread+0xea/0x2f8 > [438326.625196] [<81039152>] ? manage_workers.isra.37+0x21a/0x21a > [438326.625200] [<8103d4c4>] kthread+0x8e/0x90 > [438326.625207] [<813af737>] ret_from_kernel_thread+0x1b/0x28 > [438326.625211] [<8103d436>] ? kthread_worker_fn+0xd3/0xd3 > [438326.625214] XFS (sdb3): Corruption detected. Unmount and run xfs_repair > [438326.625271] XFS (sdb3): SB validate failed with error 22. > looks this problem is irrelevant to CRC check is enabled or not, and Eric has fixed it: commit 31625f28ad7be67701dc4cefcf52087addd88af4 xfs: don't emit corruption noise on fs probes Thanks, -Jeff > I don't know if the CentOS kernel has any extra patches that would enable > this filesystem to be mounted. > > There might be a way to bisect or revert the git xfsprogs back before dirent > and giving that a try. However, it seems best to start working with v5/CRC > XFS starting with kernel 3.11. If my luck with recent AIO commits was better, > I'd recommend 3.12 instead because that's the real correct answer, problems > aside. > > Thanks! > > Michael > > _______________________________________________ > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to use increased number of ACL entries? 2013-11-04 4:35 ` Jeff Liu @ 2013-11-04 5:52 ` Michael L. Semon 2013-11-04 15:05 ` Kasparek Tomas 0 siblings, 1 reply; 13+ messages in thread From: Michael L. Semon @ 2013-11-04 5:52 UTC (permalink / raw) To: Jeff Liu; +Cc: Kasparek Tomas, Eric Sandeen, xfs On 11/03/2013 11:35 PM, Jeff Liu wrote: > On 11/04/2013 12:18 PM, Michael L. Semon wrote: > >> On 11/03/2013 09:37 PM, Eric Sandeen wrote: >>> On 11/3/13, 6:39 PM, Dave Chinner wrote: >>>> On Sun, Nov 03, 2013 at 09:17:04AM +0100, Kasparek Tomas wrote: >>>>> Hello, >>>>> >>>>> I'm trying to get more then 25 ACLs entries to work according to >>>>> http://oss.sgi.com/pipermail/xfs/2013-May/026544.html . I'm running 3.10.x >>>>> kernel which seems to contain these changes. I understand, that this is >>>>> on-disk format change, so I expect to need new xfsprogs too. I tried the >>>>> version from CentOS 6.4 (3.1.1) and one from git repo ( >>>>> git://oss.sgi.com/xfs/cmds/xfsprogs), but still it fails to create more then >>>>> 25 ACL entries (21 user defined). Is there something I'm still missing? >>>> >>>> You haven't told mkfs to change the on disk format to enable more >>>> than 25 ACLs. Only the version from git will do it, and your CentOS >>>> kernel will not support it. >>> >>> but the 3.10.x kernel you're running will IIRC; use "-m crc=1" on the mkfs.xfs >>> commandline from a git mkfs.xfs. >>> >>> -Eric >>> >>>> Cheers, >>>> >>>> Dave. >> >> Y'know, Eric, your best suggestions are always made when I'm working on a >> non-test PC that I don't really want to touch ;-) But anyway, (i686 Pentium >> 4, kernel 3.10.17)... >> >> git xfsprogs will make the filesystem in question: >> >> root@bpserver:/storage/devel/git-xfsprogs# mkfs/mkfs.xfs /dev/sdb3 >> mkfs.xfs: /dev/sdb3 appears to contain an existing filesystem (swap). >> mkfs.xfs: Use the -f option to force overwrite. >> root@bpserver:/storage/devel/git-xfsprogs# mkfs/mkfs.xfs -f -m crc=1 /dev/sdb3 >> meta-data=/dev/sdb3 isize=512 agcount=4, agsize=65536 blks >> = sectsz=512 attr=2, projid32bit=1 >> = crc=1 >> data = bsize=4096 blocks=262144, imaxpct=25 >> = sunit=0 swidth=0 blks >> naming =version 2 bsize=4096 ascii-ci=0 ftype=1 >> log =internal log bsize=4096 blocks=12800, version=2 >> = sectsz=512 sunit=0 blks, lazy-count=1 >> realtime =none extsz=4096 blocks=0, rtextents=0 >> >> However, it should be dirent (ftype=1 in the above output) that keeps a >> vanilla 3.10.17 kernel from mounting the resulting filesystem: >> >> [438326.624667] XFS (sdb3): Version 5 superblock detected. This kernel has EXPERIMENTAL support enabled! >> [438326.624667] Use of these features in this kernel is at your own risk! >> [438326.624762] XFS (sdb3): Superblock has unknown incompatible features (0x1) enabled. >> [438326.624762] Filesystem can not be safely mounted by this kernel. >> [438326.624769] 8d76c000: 58 46 53 42 00 00 10 00 00 00 00 00 00 04 00 00 XFSB............ >> [438326.624833] 8d76c010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >> [438326.624897] 8d76c020: 60 b9 e2 ff 8f c5 41 f5 87 32 bc ea 7d 7b 8c 1b `.....A..2..}{.. >> [438326.624961] 8d76c030: 00 00 00 00 00 02 00 04 00 00 00 00 00 00 00 40 ...............@ >> [438326.625026] XFS (sdb3): Internal error xfs_sb_read_verify at line 730 of file fs/xfs/xfs_mount.c. Caller 0x81123144 >> [438326.625026] >> [438326.625108] CPU: 0 PID: 58 Comm: kworker/0:1H Not tainted 3.10.17 #2 >> [438326.625110] Hardware name: Dell Computer Corporation Dimension 3000 /0N6381, BIOS A02 11/08/2004 >> [438326.625119] Workqueue: xfslogd xfs_buf_iodone_work >> [438326.625123] a4b38400 a4b38400 bde73e90 813ab881 bde73eb4 81124b91 a4b38400 00000008 >> [438326.625130] 814593ac 813c5439 000002da 8145fee6 81123144 bde73ed4 81124bd6 8145fee6 >> [438326.625136] 000002da 81123144 954cf500 00000016 a4b38400 bde73f00 811693c4 8d76c000 >> [438326.625142] Call Trace: >> [438326.625151] [<813ab881>] dump_stack+0x16/0x18 >> [438326.625155] [<81124b91>] xfs_error_report+0x45/0x47 >> [438326.625160] [<81123144>] ? xfs_buf_iodone_work+0x52/0x67 >> [438326.625163] [<81124bd6>] xfs_corruption_error+0x43/0x5d >> [438326.625167] [<81123144>] ? xfs_buf_iodone_work+0x52/0x67 >> [438326.625173] [<811693c4>] xfs_sb_read_verify+0xd4/0xe5 >> [438326.625177] [<81123144>] ? xfs_buf_iodone_work+0x52/0x67 >> [438326.625181] [<81123144>] xfs_buf_iodone_work+0x52/0x67 >> [438326.625187] [<81038920>] process_one_work+0xd5/0x2eb >> [438326.625191] [<8103923c>] worker_thread+0xea/0x2f8 >> [438326.625196] [<81039152>] ? manage_workers.isra.37+0x21a/0x21a >> [438326.625200] [<8103d4c4>] kthread+0x8e/0x90 >> [438326.625207] [<813af737>] ret_from_kernel_thread+0x1b/0x28 >> [438326.625211] [<8103d436>] ? kthread_worker_fn+0xd3/0xd3 >> [438326.625214] XFS (sdb3): Corruption detected. Unmount and run xfs_repair >> [438326.625271] XFS (sdb3): SB validate failed with error 22. >> > > looks this problem is irrelevant to CRC check is enabled or not, and > Eric has fixed it: > > commit 31625f28ad7be67701dc4cefcf52087addd88af4 > xfs: don't emit corruption noise on fs probes > > > Thanks, > -Jeff We shall see. I was providing some output to give an expectation of how it would look. The one line that showed the feature bits looked like this: >> [438326.624762] XFS (sdb3): Superblock has unknown incompatible features (0x1) enabled. >> I don't know if the CentOS kernel has any extra patches that would enable >> this filesystem to be mounted. >> >> There might be a way to bisect or revert the git xfsprogs back before dirent >> and giving that a try. However, it seems best to start working with v5/CRC >> XFS starting with kernel 3.11. If my luck with recent AIO commits was better, >> I'd recommend 3.12 instead because that's the real correct answer, problems >> aside. >> >> Thanks! >> >> Michael That stated, I found some time to revert the git xfsprogs, and there was success in making more than 25 ACLs on vanilla kernel 3.10.17. Again, this is not recommended--the later kernel and userspace patches are there for good reason--but the output is pasted after my closing. Good luck! Michael Script started on Mon 04 Nov 2013 12:32:08 AM EST root@bpserver:/storage/devel/git-xfsprogs# git branch early_branch 88cd79be1aa1f6947d20da102fbf5bb128d70ce1 root@bpserver:/storage/devel/git-xfsprogs# git checkout early_branch Switched to branch 'early_branch' root@bpserver:/storage/devel/git-xfsprogs# git log commit 88cd79be1aa1f6947d20da102fbf5bb128d70ce1 Author: Dave Chinner <dchinner@redhat.com> Date: Wed Sep 4 22:05:50 2013 +0000 xfs: Add xfs_log_rlimit.c Add source files for xfs_log_rlimit.c The new file is used for log size calculations and validation shared with userspace. [rest of `git log` snipped] root@bpserver:/storage/devel/git-xfsprogs# make distclean; make [make OK, output snipped] root@bpserver:/storage/devel/git-xfsprogs# cat /proc/swaps Filename Type Size Used Priority /dev/sdb3 partition 1048572 0 -1 root@bpserver:/storage/devel/git-xfsprogs# swapoff /dev/sdb3 root@bpserver:/storage/devel/git-xfsprogs# dd if=/dev/zero of=/dev/sdb3 bs=4k dd: writing '/dev/sdb3': No space left on device 262145+0 records in 262144+0 records out 1073741824 bytes (1.1 GB) copied, 18.8771 s, 56.9 MB/s root@bpserver:/storage/devel/git-xfsprogs# mkfs/mkfs.xfs -m crc=1 /dev/sdb3 meta-data=/dev/sdb3 isize=512 agcount=4, agsize=65536 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 data = bsize=4096 blocks=262144, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=12800, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 Version 5 superblock detected. xfsprogs has EXPERIMENTAL support enabled! Use of these features is at your own risk! root@bpserver:/storage/devel/git-xfsprogs# mount -t xfs /dev/sdb3 /mnt/tmp root@bpserver:/storage/devel/git-xfsprogs# mount | grep sdb3 /dev/sdb3 on /mnt/tmp type xfs (rw) root@bpserver:/storage/devel/git-xfsprogs# cd /mnt/tmp root@bpserver:/mnt/tmp# touch testfile root@bpserver:/mnt/tmp# for a in `seq 1 28`; do setfacl -m u:$a:rw- testfile; done root@bpserver:/mnt/tmp# getfacl testfile # file: testfile # owner: root # group: root user::rw- user:bin:rw- user:daemon:rw- user:adm:rw- user:lp:rw- user:sync:rw- user:shutdown:rw- user:halt:rw- user:mail:rw- user:news:rw- user:uucp:rw- user:operator:rw- user:games:rw- user:13:rw- user:ftp:rw- user:15:rw- user:16:rw- user:17:rw- user:18:rw- user:19:rw- user:20:rw- user:21:rw- user:22:rw- user:23:rw- user:24:rw- user:smmsp:rw- user:26:rw- user:mysql:rw- user:28:rw- group::r-- mask::rw- other::r-- root@bpserver:/mnt/tmp# cd - /storage/devel/git-xfsprogs root@bpserver:/storage/devel/git-xfsprogs# umount /mnt/tmp/ root@bpserver:/storage/devel/git-xfsprogs# dmesg [ 4648.112001] XFS (sdb3): Version 5 superblock detected. This kernel has EXPERIMENTAL support enabled! [ 4648.112001] Use of these features in this kernel is at your own risk! [ 4648.112233] XFS (sdb3): Mounting Filesystem [ 4648.227979] XFS (sdb3): Ending clean mount root@bpserver:/storage/devel/git-xfsprogs# exit Script done on Mon 04 Nov 2013 12:40:26 AM EST _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to use increased number of ACL entries? 2013-11-04 5:52 ` Michael L. Semon @ 2013-11-04 15:05 ` Kasparek Tomas 0 siblings, 0 replies; 13+ messages in thread From: Kasparek Tomas @ 2013-11-04 15:05 UTC (permalink / raw) To: Michael L. Semon; +Cc: Jeff Liu, Eric Sandeen, xfs [-- Attachment #1.1: Type: text/plain, Size: 2974 bytes --] On Mon, Nov 04, 2013 at 12:52:07AM -0500, Michael L. Semon wrote: > >>> but the 3.10.x kernel you're running will IIRC; use "-m crc=1" on the mkfs.xfs > >>> commandline from a git mkfs.xfs. Did tried and ended with the same problem for filesystem mounting. > >> root@bpserver:/storage/devel/git-xfsprogs# mkfs/mkfs.xfs -f -m crc=1 /dev/sdb3 > >> However, it should be dirent (ftype=1 in the above output) that keeps a > >> vanilla 3.10.17 kernel from mounting the resulting filesystem: > >> > >> [438326.624667] XFS (sdb3): Version 5 superblock detected. This kernel has EXPERIMENTAL support enabled! > >> [438326.624667] Use of these features in this kernel is at your own risk! > >> [438326.624762] XFS (sdb3): Superblock has unknown incompatible features (0x1) enabled. > >> [438326.624762] Filesystem can not be safely mounted by this kernel. > > > > looks this problem is irrelevant to CRC check is enabled or not, and > > Eric has fixed it: > > > > commit 31625f28ad7be67701dc4cefcf52087addd88af4 > > xfs: don't emit corruption noise on fs probes Will try this. > >> I don't know if the CentOS kernel has any extra patches that would enable > >> this filesystem to be mounted. I use vanilla longterm 3.10.x, not CentOS kernel, that is too old for my HW. > >> There might be a way to bisect or revert the git xfsprogs back before dirent > >> and giving that a try. However, it seems best to start working with v5/CRC > >> XFS starting with kernel 3.11. If my luck with recent AIO commits was better, > >> I'd recommend 3.12 instead because that's the real correct answer, problems > >> aside. I have to use longterm kernel and 3.10.x is the latest available. As I have seen the commit for more ACLs there, I expected it should be possible to get it working for this version (https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=0a8aa1939777dd114479677f0044652c1fd72398) > That stated, I found some time to revert the git xfsprogs, and there was > success in making more than 25 ACLs on vanilla kernel 3.10.17. Again, > this is not recommended--the later kernel and userspace patches are there > for good reason--but the output is pasted after my closing. I will repeat your directions and test it. However, if you as XFS devels do not see these to be stable enough to be used in production environment, I may still revert to some other solution (unix groups) even if these are a night mare to administer for my situation. Thanks for all the info and advices. Regards -- Tomas Kasparek E-mail: kasparek@fit.vutbr.cz CVT FIT VUT Brno, L127 Web: http://www.fit.vutbr.cz/~kasparek Bozetechova 1, 612 66 Fax: +420 54114-1270 Brno, Czech Republic Phone: +420 54114-1220 jabber: tomas.kasparek@jabber.cz GPG: 2F1E 1AAF FD3B CFA3 1537 63BD DCBE 18FF A035 53BC May the command line live forever! [-- Attachment #1.2: Type: application/pgp-signature, Size: 196 bytes --] [-- Attachment #2: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to use increased number of ACL entries? 2013-11-04 4:18 ` Michael L. Semon 2013-11-04 4:35 ` Jeff Liu @ 2013-11-04 14:24 ` Eric Sandeen 2013-11-04 15:10 ` Kasparek Tomas 2013-11-04 20:53 ` Dave Chinner 1 sibling, 2 replies; 13+ messages in thread From: Eric Sandeen @ 2013-11-04 14:24 UTC (permalink / raw) To: Michael L. Semon, Dave Chinner, Kasparek Tomas; +Cc: xfs On 11/3/13, 10:18 PM, Michael L. Semon wrote: > On 11/03/2013 09:37 PM, Eric Sandeen wrote: >> On 11/3/13, 6:39 PM, Dave Chinner wrote: >>> On Sun, Nov 03, 2013 at 09:17:04AM +0100, Kasparek Tomas wrote: >>>> Hello, >>>> >>>> I'm trying to get more then 25 ACLs entries to work according to >>>> http://oss.sgi.com/pipermail/xfs/2013-May/026544.html . I'm running 3.10.x >>>> kernel which seems to contain these changes. I understand, that this is >>>> on-disk format change, so I expect to need new xfsprogs too. I tried the >>>> version from CentOS 6.4 (3.1.1) and one from git repo ( >>>> git://oss.sgi.com/xfs/cmds/xfsprogs), but still it fails to create more then >>>> 25 ACL entries (21 user defined). Is there something I'm still missing? >>> >>> You haven't told mkfs to change the on disk format to enable more >>> than 25 ACLs. Only the version from git will do it, and your CentOS >>> kernel will not support it. >> >> but the 3.10.x kernel you're running will IIRC; use "-m crc=1" on the mkfs.xfs >> commandline from a git mkfs.xfs. >> >> -Eric >> >>> Cheers, >>> >>> Dave. > > Y'know, Eric, your best suggestions are always made when I'm working on a > non-test PC that I don't really want to touch ;-) But anyway, (i686 Pentium > 4, kernel 3.10.17)... > > git xfsprogs will make the filesystem in question: > > root@bpserver:/storage/devel/git-xfsprogs# mkfs/mkfs.xfs /dev/sdb3 > mkfs.xfs: /dev/sdb3 appears to contain an existing filesystem (swap). > mkfs.xfs: Use the -f option to force overwrite. > root@bpserver:/storage/devel/git-xfsprogs# mkfs/mkfs.xfs -f -m crc=1 /dev/sdb3 > meta-data=/dev/sdb3 isize=512 agcount=4, agsize=65536 blks > = sectsz=512 attr=2, projid32bit=1 > = crc=1 > data = bsize=4096 blocks=262144, imaxpct=25 > = sunit=0 swidth=0 blks > naming =version 2 bsize=4096 ascii-ci=0 ftype=1 > log =internal log bsize=4096 blocks=12800, version=2 > = sectsz=512 sunit=0 blks, lazy-count=1 > realtime =none extsz=4096 blocks=0, rtextents=0 > > However, it should be dirent (ftype=1 in the above output) that keeps a > vanilla 3.10.17 kernel from mounting the resulting filesystem: I'm sorry, you are right - it hit kernel v3.11: 5c87d4bc1a86bd6e6754ac3d6e111d776ddcfe57 xfs: increase number of ACL entries for V5 superblocks $ git describe --contains 5c87d4bc1a86bd6e6754ac3d6e111d776ddcfe57 v3.11-rc1~18^2~41 -Eric _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to use increased number of ACL entries? 2013-11-04 14:24 ` Eric Sandeen @ 2013-11-04 15:10 ` Kasparek Tomas 2013-11-04 20:46 ` Dave Chinner 2013-11-04 20:53 ` Dave Chinner 1 sibling, 1 reply; 13+ messages in thread From: Kasparek Tomas @ 2013-11-04 15:10 UTC (permalink / raw) To: Eric Sandeen; +Cc: Michael L. Semon, xfs [-- Attachment #1.1: Type: text/plain, Size: 1016 bytes --] On Mon, Nov 04, 2013 at 08:24:25AM -0600, Eric Sandeen wrote: > > However, it should be dirent (ftype=1 in the above output) that keeps a > > vanilla 3.10.17 kernel from mounting the resulting filesystem: > > I'm sorry, you are right - it hit kernel v3.11: > > 5c87d4bc1a86bd6e6754ac3d6e111d776ddcfe57 xfs: increase number of ACL entries for V5 superblocks > > $ git describe --contains 5c87d4bc1a86bd6e6754ac3d6e111d776ddcfe57 > v3.11-rc1~18^2~41 And get to stable 3.10 later. https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=0a8aa1939777dd114479677f0044652c1fd72398 -- Tomas Kasparek E-mail: kasparek@fit.vutbr.cz CVT FIT VUT Brno, L127 Web: http://www.fit.vutbr.cz/~kasparek Bozetechova 1, 612 66 Fax: +420 54114-1270 Brno, Czech Republic Phone: +420 54114-1220 jabber: tomas.kasparek@jabber.cz GPG: 2F1E 1AAF FD3B CFA3 1537 63BD DCBE 18FF A035 53BC May the command line live forever! [-- Attachment #1.2: Type: application/pgp-signature, Size: 196 bytes --] [-- Attachment #2: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to use increased number of ACL entries? 2013-11-04 15:10 ` Kasparek Tomas @ 2013-11-04 20:46 ` Dave Chinner 2013-11-05 22:03 ` Michael L. Semon 0 siblings, 1 reply; 13+ messages in thread From: Dave Chinner @ 2013-11-04 20:46 UTC (permalink / raw) To: Kasparek Tomas; +Cc: Michael L. Semon, Eric Sandeen, xfs On Mon, Nov 04, 2013 at 04:10:50PM +0100, Kasparek Tomas wrote: > On Mon, Nov 04, 2013 at 08:24:25AM -0600, Eric Sandeen wrote: > > > However, it should be dirent (ftype=1 in the above output) that keeps a > > > vanilla 3.10.17 kernel from mounting the resulting filesystem: > > > > I'm sorry, you are right - it hit kernel v3.11: > > > > 5c87d4bc1a86bd6e6754ac3d6e111d776ddcfe57 xfs: increase number of ACL entries for V5 superblocks > > > > $ git describe --contains 5c87d4bc1a86bd6e6754ac3d6e111d776ddcfe57 > > v3.11-rc1~18^2~41 > > And get to stable 3.10 later. > > https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=0a8aa1939777dd114479677f0044652c1fd72398 No, that never went into the 3.10 stable tree, and nor should it. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to use increased number of ACL entries? 2013-11-04 20:46 ` Dave Chinner @ 2013-11-05 22:03 ` Michael L. Semon 2013-11-05 22:46 ` Ben Myers 0 siblings, 1 reply; 13+ messages in thread From: Michael L. Semon @ 2013-11-05 22:03 UTC (permalink / raw) To: Dave Chinner, Kasparek Tomas; +Cc: Eric Sandeen, xfs On 11/04/2013 03:46 PM, Dave Chinner wrote: > On Mon, Nov 04, 2013 at 04:10:50PM +0100, Kasparek Tomas wrote: >> On Mon, Nov 04, 2013 at 08:24:25AM -0600, Eric Sandeen wrote: >>>> However, it should be dirent (ftype=1 in the above output) that keeps a >>>> vanilla 3.10.17 kernel from mounting the resulting filesystem: >>> >>> I'm sorry, you are right - it hit kernel v3.11: >>> >>> 5c87d4bc1a86bd6e6754ac3d6e111d776ddcfe57 xfs: increase number of ACL entries for V5 superblocks >>> >>> $ git describe --contains 5c87d4bc1a86bd6e6754ac3d6e111d776ddcfe57 >>> v3.11-rc1~18^2~41 >> >> And get to stable 3.10 later. >> >> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=0a8aa1939777dd114479677f0044652c1fd72398 > > No, that never went into the 3.10 stable tree, and nor should it. > > Cheers, > > Dave. > >From the patch in the link above, I get this snippet from 3.10.17's xfs_acl.c... /* * If we have a cached ACLs value just return it, not need to * go out to the disk. */ len = XFS_ACL_MAX_SIZE(ip->i_mount); xfs_acl = kzalloc(len, GFP_KERNEL); if (!xfs_acl) return ERR_PTR(-ENOMEM); ...and this from 3.10.17's xfs_acl.h... /* * The number of ACL entries allowed is defined by the on-disk format. * For v4 superblocks, that is limited to 25 entries. For v5 superblocks, it is * limited only by the maximum size of the xattr that stores the information. */ #define XFS_ACL_MAX_ENTRIES(mp) \ (xfs_sb_version_hascrc(&mp->m_sb) \ ? (XATTR_SIZE_MAX - sizeof(struct xfs_acl)) / \ sizeof(struct xfs_acl_entry) \ : 25) #define XFS_ACL_MAX_SIZE(mp) \ (sizeof(struct xfs_acl) + \ sizeof(struct xfs_acl_entry) * XFS_ACL_MAX_ENTRIES((mp))) ...so that patch seems to have made it into vanilla 3.10.17 somehow. I checked the Changelogs for 3.10.x but don't know how to check a Changelog for just 3.10 stable. Therefore, I unpacked a kernel.org 3.10 tarball, and these changes are in there as well. For lack of skills, I can point only to this in the kernel git, where this is the master branch. xfs-oss/master is downloaded but not merged: commit e6395b68ad09a835f058da31bad0fe23d3882659 Merge: 29eb778 0a8aa19 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Thu Jun 6 16:15:25 2013 -0700 Merge tag 'for-linus-v3.10-rc5' of git://oss.sgi.com/xfs/xfs Pull more xfs updates from Ben Myers: "Here are several fixes for filesystems with CRC support turned on: fixes for quota, remote attributes, and recovery. There is also some feature work related to CRCs: the implementation of CRCs for the inode unlinked lists, disabling noattr2/attr2 options when appropriate, and bumping the maximum number of ACLs. Maybe somebody with a git of stable could shed some light... Thanks for reading! Michael _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to use increased number of ACL entries? 2013-11-05 22:03 ` Michael L. Semon @ 2013-11-05 22:46 ` Ben Myers 0 siblings, 0 replies; 13+ messages in thread From: Ben Myers @ 2013-11-05 22:46 UTC (permalink / raw) To: Michael L. Semon; +Cc: Eric Sandeen, Kasparek Tomas, xfs On Tue, Nov 05, 2013 at 05:03:13PM -0500, Michael L. Semon wrote: > On 11/04/2013 03:46 PM, Dave Chinner wrote: > > On Mon, Nov 04, 2013 at 04:10:50PM +0100, Kasparek Tomas wrote: > >> On Mon, Nov 04, 2013 at 08:24:25AM -0600, Eric Sandeen wrote: > >>>> However, it should be dirent (ftype=1 in the above output) that keeps a > >>>> vanilla 3.10.17 kernel from mounting the resulting filesystem: > >>> > >>> I'm sorry, you are right - it hit kernel v3.11: > >>> > >>> 5c87d4bc1a86bd6e6754ac3d6e111d776ddcfe57 xfs: increase number of ACL entries for V5 superblocks > >>> > >>> $ git describe --contains 5c87d4bc1a86bd6e6754ac3d6e111d776ddcfe57 > >>> v3.11-rc1~18^2~41 > >> > >> And get to stable 3.10 later. > >> > >> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=0a8aa1939777dd114479677f0044652c1fd72398 > > > > No, that never went into the 3.10 stable tree, and nor should it. > > > > Cheers, > > > > Dave. > > > > >From the patch in the link above, I get this snippet from 3.10.17's > xfs_acl.c... > > /* > * If we have a cached ACLs value just return it, not need to > * go out to the disk. > */ > len = XFS_ACL_MAX_SIZE(ip->i_mount); > xfs_acl = kzalloc(len, GFP_KERNEL); > if (!xfs_acl) > return ERR_PTR(-ENOMEM); > > ...and this from 3.10.17's xfs_acl.h... > > /* > * The number of ACL entries allowed is defined by the on-disk format. > * For v4 superblocks, that is limited to 25 entries. For v5 superblocks, it is > * limited only by the maximum size of the xattr that stores the information. > */ > #define XFS_ACL_MAX_ENTRIES(mp) \ > (xfs_sb_version_hascrc(&mp->m_sb) \ > ? (XATTR_SIZE_MAX - sizeof(struct xfs_acl)) / \ > sizeof(struct xfs_acl_entry) \ > : 25) > > #define XFS_ACL_MAX_SIZE(mp) \ > (sizeof(struct xfs_acl) + \ > sizeof(struct xfs_acl_entry) * XFS_ACL_MAX_ENTRIES((mp))) > > ...so that patch seems to have made it into vanilla 3.10.17 somehow. > I checked the Changelogs for 3.10.x but don't know how to check a > Changelog for just 3.10 stable. Therefore, I unpacked a kernel.org 3.10 > tarball, and these changes are in there as well. > > For lack of skills, I can point only to this in the kernel git, where > this is the master branch. xfs-oss/master is downloaded but not merged: > > commit e6395b68ad09a835f058da31bad0fe23d3882659 > Merge: 29eb778 0a8aa19 > Author: Linus Torvalds <torvalds@linux-foundation.org> > Date: Thu Jun 6 16:15:25 2013 -0700 > > Merge tag 'for-linus-v3.10-rc5' of git://oss.sgi.com/xfs/xfs > > Pull more xfs updates from Ben Myers: > "Here are several fixes for filesystems with CRC support turned on: > fixes for quota, remote attributes, and recovery. There is also some > feature work related to CRCs: the implementation of CRCs for the inode > unlinked lists, disabling noattr2/attr2 options when appropriate, and > bumping the maximum number of ACLs. > > Maybe somebody with a git of stable could shed some light... This patch was committed in the 3.11-rc1 dev window and I explicitly cherry picked it to 3.10 and sent a pull request containing it prior to 3.10-rc5. So there are two commits... one for 3.11 (5c87d4bc) and one for 3.10-rc5 (0a8aa193), which for clarity has this line in it's commit header: (cherry picked from commit 5c87d4bc1a86bd6e6754ac3d6e111d776ddcfe57) IIRC we did this because we wanted to get as many of the v5 disk format changes in during 3.10 so that we wouldn't need to burn feature bits on them later. HTH, Ben _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: How to use increased number of ACL entries? 2013-11-04 14:24 ` Eric Sandeen 2013-11-04 15:10 ` Kasparek Tomas @ 2013-11-04 20:53 ` Dave Chinner 1 sibling, 0 replies; 13+ messages in thread From: Dave Chinner @ 2013-11-04 20:53 UTC (permalink / raw) To: Eric Sandeen; +Cc: Kasparek Tomas, Michael L. Semon, xfs On Mon, Nov 04, 2013 at 08:24:25AM -0600, Eric Sandeen wrote: > On 11/3/13, 10:18 PM, Michael L. Semon wrote: > > On 11/03/2013 09:37 PM, Eric Sandeen wrote: > >> On 11/3/13, 6:39 PM, Dave Chinner wrote: > >>> On Sun, Nov 03, 2013 at 09:17:04AM +0100, Kasparek Tomas wrote: > >>>> Hello, > >>>> > >>>> I'm trying to get more then 25 ACLs entries to work according to > >>>> http://oss.sgi.com/pipermail/xfs/2013-May/026544.html . I'm running 3.10.x > >>>> kernel which seems to contain these changes. I understand, that this is > >>>> on-disk format change, so I expect to need new xfsprogs too. I tried the > >>>> version from CentOS 6.4 (3.1.1) and one from git repo ( > >>>> git://oss.sgi.com/xfs/cmds/xfsprogs), but still it fails to create more then > >>>> 25 ACL entries (21 user defined). Is there something I'm still missing? > >>> > >>> You haven't told mkfs to change the on disk format to enable more > >>> than 25 ACLs. Only the version from git will do it, and your CentOS > >>> kernel will not support it. > >> > >> but the 3.10.x kernel you're running will IIRC; use "-m crc=1" on the mkfs.xfs > >> commandline from a git mkfs.xfs. > >> > >> -Eric > >> > >>> Cheers, > >>> > >>> Dave. > > > > Y'know, Eric, your best suggestions are always made when I'm working on a > > non-test PC that I don't really want to touch ;-) But anyway, (i686 Pentium > > 4, kernel 3.10.17)... > > > > git xfsprogs will make the filesystem in question: > > > > root@bpserver:/storage/devel/git-xfsprogs# mkfs/mkfs.xfs /dev/sdb3 > > mkfs.xfs: /dev/sdb3 appears to contain an existing filesystem (swap). > > mkfs.xfs: Use the -f option to force overwrite. > > root@bpserver:/storage/devel/git-xfsprogs# mkfs/mkfs.xfs -f -m crc=1 /dev/sdb3 > > meta-data=/dev/sdb3 isize=512 agcount=4, agsize=65536 blks > > = sectsz=512 attr=2, projid32bit=1 > > = crc=1 > > data = bsize=4096 blocks=262144, imaxpct=25 > > = sunit=0 swidth=0 blks > > naming =version 2 bsize=4096 ascii-ci=0 ftype=1 > > log =internal log bsize=4096 blocks=12800, version=2 > > = sectsz=512 sunit=0 blks, lazy-count=1 > > realtime =none extsz=4096 blocks=0, rtextents=0 > > > > However, it should be dirent (ftype=1 in the above output) that keeps a > > vanilla 3.10.17 kernel from mounting the resulting filesystem: > > I'm sorry, you are right - it hit kernel v3.11: > > 5c87d4bc1a86bd6e6754ac3d6e111d776ddcfe57 xfs: increase number of ACL entries for V5 superblocks > > $ git describe --contains 5c87d4bc1a86bd6e6754ac3d6e111d776ddcfe57 > v3.11-rc1~18^2~41 And a current git mkfs for -m crc=1 sets ftype which didn't hit until: $ glo -n 1 0cb97766 0cb9776 xfs: Add read-only support for dirent filetype field $ git describe --contains 0cb97766 xfs-for-linus-v3.12-rc1~19 $ So a 3.12 kernel will be required to use it with a mkfs from the git tree. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-11-05 22:46 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-11-03 8:17 How to use increased number of ACL entries? Kasparek Tomas 2013-11-04 0:39 ` Dave Chinner 2013-11-04 2:37 ` Eric Sandeen 2013-11-04 4:18 ` Michael L. Semon 2013-11-04 4:35 ` Jeff Liu 2013-11-04 5:52 ` Michael L. Semon 2013-11-04 15:05 ` Kasparek Tomas 2013-11-04 14:24 ` Eric Sandeen 2013-11-04 15:10 ` Kasparek Tomas 2013-11-04 20:46 ` Dave Chinner 2013-11-05 22:03 ` Michael L. Semon 2013-11-05 22:46 ` Ben Myers 2013-11-04 20:53 ` Dave Chinner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox