xattr values are capped at a single filesystem block (~4 KiB). Where this actually bites is Finder: copy a file with a large resource fork (or certain com.apple.* attributes) and those attributes error out while the file data copies fine — a "mostly worked" copy, which is the worst kind of confusing.
ext4 stores oversized xattrs in a separate inode (the ea_inode feature) rather than inline or in the single xattr block. lwext4's xattr code (ext4_xattr.c) doesn't implement ea_inode, so we inherit the one-block ceiling. Fixing it is an lwext4-level feature (read + write of ea_inode), so it's a chunk of work — lower priority than the perf items, but worth tracking because the failure mode is so opaque.
xattr values are capped at a single filesystem block (~4 KiB). Where this actually bites is Finder: copy a file with a large resource fork (or certain
com.apple.*attributes) and those attributes error out while the file data copies fine — a "mostly worked" copy, which is the worst kind of confusing.ext4 stores oversized xattrs in a separate inode (the
ea_inodefeature) rather than inline or in the single xattr block. lwext4's xattr code (ext4_xattr.c) doesn't implementea_inode, so we inherit the one-block ceiling. Fixing it is an lwext4-level feature (read + write ofea_inode), so it's a chunk of work — lower priority than the perf items, but worth tracking because the failure mode is so opaque.