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