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 :). -- 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
