On Fri, Dec 13, 2013 at 02:16:54PM -0200, Carlos Maiolino wrote: > Hi, > > > Hi Folks, > > > > While looking into the behaviour of XFS in case of running out of the > > maximum number of supported acl entries, I observed that we would > > return various different errors in this situation. As per Christoph's > > suggestion, I gathered up them from some common file systems with a > > simple tests which were shown as following: > > > > Btrfs: No space left on device (ENOSPC) > > Ext3: No space left on device (ENOSPC) > > Ext4: No space left oo long (E2BIG) > > F2fs: Numerical result out of range (ERANGE) > > OCFS2: Argument list too long (E2BIG) > > XFS: Invalid argument (EINVAL) > > > > It seems that return either above error would mislead the end user, though > > Eric's Sandeen once pointed out that ENOSPC should be used in this case in > > terms of the setxattr(2) man page. > > <quote> > > If there is insufficient space remaining to store the extended attribute, > > errno is set to either ENOSPC, or EDQUOT if quota enforcement was the cause. > > > > However, the "insufficient space" is obscure, it might be the file system > > space or no more space in metadata blocks, etc... > > > > Hence, should we consolidate this scenario to figure out a more clearer > > common error? > > > > > Consolidate the erros here would make things much more easier for > users/applications which has a heavy usage of xattrs, for example, glusterfs. > But, I still think that -ENOSPC or -EDQUOT are the best and easier approaches > here. Whether it's FS space or metadata blocks, both of them are lack of space, > which properly describes why a tentative to add a new xattr failed. > At least for me, this looks much easier than add a new error flag and make all > applications using xattrs to change their code to fit new behavior (or maybe > they'll need to change it anyway to fit -ENOSPC :). This isn't an "out-of-space" error where there are no more resources available to create the ACL. Therefore, ENOSPC is not an appropriate error. What we are hitting a maximum size limit defined by XATTR implemenation used to store the ACLs. Hence the error is equivalent to a user trying to set an xattr of larger than XATTR_SIZE_MAX. In that case, we have: setxattr: E2BIG getxattr: E2BIG xfs_attrmulti_attr_get: EINVAL xfs_attrmulti_attr_set: EINVAL So, what we see here is that XFS returning EINVAL for too many ACLs is internally consistent with it's ioctl-based xattr interfaces, but only JFS and OCFS2 are internally consistent with the VFS xattr code. Hence, IMO, the correct thing to do here is make everything consistent with the VFS [gs]etxattr calls and return E2BIG when the xattr that holds the ACLs grows too large to fit within the size limits bounded by the xattr implementation.... Cheers, Dave. > > -- > Carlos > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
