>> But once we have the 64-bit machine, we'd like to have the
>> filesystem adapted too. As it is now, ext2 still is 32-bit
>> and not likely to change ...
>
> Actually, it *is* likely to change. After I enlarge the VM's
> range, the ext2fs is my next target.
What are your plans? If you've not decided, here is space-saving
suggestion for the inode:
struct ext2_inode {
__u16 i_mode; /* File mode */
__u16 i_uid; /* Owner Uid */
__u32 i_size; /* Size in bytes */
__u32 i_atime; /* Access time */
__u32 i_ctime; /* inode Change time */
__u32 i_mtime; /* Modification time */
__u32 i_dtime; /* Deletion Time */
__u16 i_gid; /* Group Id */
__u16 i_links_count; /* Links count */
__u32 i_blocks; /* Blocks count */
__u32 i_flags; /* File flags */
union {
__u32 i_translator; /* translator (Hurd only) */
__u32 i_res_fork; /* resource fork (Linux privs) */
} u1;
__u32 i_block[EXT2_N_BLOCKS];/* Pointers to blocks */
__u32 i_version; /* File version (for NFS) */
__u32 i_file_acl; /* File ACL */
union {
__u32 i_dir_acl; /* Directory ACL (directories only) */
__u32 i_size_high; /* high 32 bits of 64-bit size */
} u2;
__u32 i_reserved1;
__u16 i_reserved2;
__u16 i_mode_high; /* extra mode bits (Hurd only) */
__u16 i_uid_high; /* high 16 bits of 32-bit UID */
__u16 i_gid_high; /* high 16 bits of 32-bit GID */
__u32 i_author; /* author (Hurd only) */
};
The 64-bit size is serious overkill, but I can't think of anything
else that can share space with i_dir_acl.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu