xfs
[Top] [All Lists]

xfs_repair issue with ACLs on v5 XFS when beyond v4 limits

To: xfs-oss <xfs@xxxxxxxxxxx>
Subject: xfs_repair issue with ACLs on v5 XFS when beyond v4 limits
From: "Michael L. Semon" <mlsemon35@xxxxxxxxx>
Date: Mon, 09 Jun 2014 23:21:03 -0400
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=66Y31Il1q6/NDZ4aLC9cnuzoX9SCFygT/dOIBO9XWSA=; b=HZd+u6hR5Mf9+w5Z5ZgGGHKU3DIKA1ZQpTXCcpSOKMmce0RMqJbw5AdeGPl0TbPANd sxKu1uCqdcjG6taCOQTs3/cQugoaJTj38Gg5q8eIlkzNCeT4wMFYO++WC8506IhSuv/X gVLBYVQCEvicKNuozu49jbiBeU2IiC3qeCJwDDOGj4U7kn2lP/a7kazgMG5EL5fI6TBP aWnNiIXQlNZiKp1x904znGY0ni/10eldI6z9oH0P5GElmhUcfEGWLfyEJ+QpBi99PM2O tUboSJJ0tNTirAk5XrCpZAgs0DQTL7Q0EZQGazsv17CKuu2e0ts2sAByeXvHBn4+B4q3 T6fQ==
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
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

<Prev in Thread] Current Thread [Next in Thread>