Although I think this is important, the patch is not ready at all.
It is hard to tell exactly what reserved fields get used because
the names were not changed. Look at this:
raw_inode->i_reserved2[0] = cpu_to_le32(inode->u.ext2_i.i_direct_bitmap)
If the names had been changed, it would be easy to resolve conflicts
with other ext2 upgrades: ACLs, privs, 32-bit UIDs, large files...
One of the algorithms is patented. Oddly though, the fast patent-free
LZO algorithm is not implemented.
This patch adds a third copy of deflate compression to the kernel.
Don't people know the kernel has a library for that? (ppp has the
other copy)
There is not much space in the inode. Some of the proposed additions
can share space with each other in unions. We seem to need:
__u32 i_res_fork Regular files only? (POSIX privs)
__u32 i_dir_acl Directories only.
__u16 i_size_high Regular files only.
__u16 i_uid_high Field already exists for the Hurd.
__u16 i_gid_high Field already exists for the Hurd.
????? i_???????? Compression, regular files only?
????? i_???????? High-resolution time stamps. (how high?)
It appears that _something_ can share space with i_dir_acl.
If not i_res_fork, then perhaps i_size_high and compression info.
If i_res_fork only applies to executables (does it?), then it can
share space with both i_dir_acl and i_size_high.
If the ext2 projects cooperate (by using unions), there is enough
space in the inode for everything.
In case anybody designs a new inode: there is a way to fit a 96-byte
fast symlink and at least 20 direct blocks for small files. It would
be nice to have a checksum too, for when the inodes get trashed.