Hi! I've been running around in circles trying to work with too many
ACLs, even losing my ability to count for a while. Along the way,
xfs_repair from git xfsprogs (last commit around May 27) is showing
the following symptoms:
On v5-superblock XFS...
1) When the ACL count is just above the limit from v4-superblock XFS--
96 is a good test figure--`xfs_repair -n` and `xfs_repair` will both
end in a segmentation fault.
2) When the ACL count is in a higher range--as low as 250, IIRC--
xfs_repair will complain about "Too many ACL entries" and proceed to
remove them. Below is a full session:
root@oldsvrhw:~# mkfs.xfs -f -m crc=1 $SCRATCH_DEV
meta-data=/dev/sdb5 isize=512 agcount=4, agsize=786432 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=0
data = bsize=4096 blocks=3145728, 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@oldsvrhw:~# mount $SCRATCH_DEV $SCRATCH_MNT
root@oldsvrhw:~# mkdir $SCRATCH_MNT/acl-dir
root@oldsvrhw:~# for a in `seq 1000 1325`; do setfacl -d -m u:$a:r-- $SCRATCH_MNT/acl-dir; done
root@oldsvrhw:~# sync
root@oldsvrhw:~# umount $SCRATCH_MNT
root@oldsvrhw:~# xfs_repair -n $SCRATCH_DEV
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
Too many ACL entries, count 330
entry contains illegal value in attribute named SGI_ACL_FILE or SGI_ACL_DEFAULT
remote attribute value check failed for entry 0, inode 67
problem with attribute contents in inode 67
would clear attr fork
bad nblocks 2 for inode 67, would reset to 0
bad anextents 1 for inode 67, would reset to 0
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.
root@oldsvrhw:~# xfs_repair $SCRATCH_DEV
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
Too many ACL entries, count 330
entry contains illegal value in attribute named SGI_ACL_FILE or SGI_ACL_DEFAULT
remote attribute value check failed for entry 0, inode 67
problem with attribute contents in inode 67
clearing inode 67 attributes
correcting nblocks for inode 67, was 2 - counted 0
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
bad attribute format 1 in inode 67, resetting value
- agno = 1
- agno = 2
- agno = 3
Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done
root@oldsvrhw:~# mount $SCRATCH_DEV $SCRATCH_MNT
root@oldsvrhw:~# getfacl $SCRATCH_MNT/acl-dir
getfacl: Removing leading '/' from absolute path names
# file: mnt/xfstests-scratch/acl-dir
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
3) When the ACL count is at the max for v5-superblock XFS--at least
with both regular and default ACL slots filled--xfs_repair will
complain of corrupt remote attributes. AFAIK, xfs_repair doesn't
bother with the "Too many ACL entries" line. Those ACLs will be
cleansed, too.
I can't tell if this is due to one missed check or three different
tiny issues.
ACLs seem to be OK when doing normal filesystem operations and using
setfacl and getfacl. No kernel stack traces have been seen on this
path of testing.
Sorry I missed this one in all of my limits testing. This was
discovered when I saw a bug in my ACL population script and hit
Ctrl-c so I could stop and edit the script. Donations of brown paper
bags are welcome...the plastic bags I'm using make it hard to breathe
and don't hide my face very well...
Test PC was a Pentium III, 733 MHz, 512 MB of RAM, running kernel
3.15.0-rc8 + xfs-oss/for-next, on Slackware 14.1.
Thanks!
Michael
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
