I think your proposal is compatible with these known
implementations.
>There are at least 48 bits we can grab _without_ causing any
>trouble for various research OSs. If we get rid of i_dtime as
>Linus Torvalds once suggested (for performance) then there
>are 80 bits available.
Better to leave i_dtime for expansion of the time range
when needed.
>Before anybody gets too excited about 64-bit file sizes and
>64-bit block counts, think about the future a bit. We will
>run out of time stamp bits before file sizes exceed 48 bits.
>It would be wise to avoid wasting bits! Going all the way to
>64-bit file sizes is far beyond what ext2 was designed for.
>Going past 48 bits without also extending the block numbers
>(stored all over the disk in indirect blocks) is pointless.
Right, 48 bits really is a lot more than 32 bits. It is enough.
>I have two suggested inode layouts that are compatible.
>From a quick grep of the source, I think these modifications
>are read-write compatible even.
>
>Suggestion 1 is nice and clean:
>
>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; /* Creation 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 */
> __u32 i_translator; /* Translator (Hurd only) */
> __u32 i_block[EXT2_N_BLOCKS];/* Pointers to blocks */
> __u32 i_version; /* File version (for NFS) */
> __u32 i_file_acl; /* File ACL */
> __u32 i_dir_acl; /* Directory ACL */
> __u32 i_reserved;
> __u16 i_size_high; /* high 16 bits of 48-bit file size */
> __u16 i_mode_high; /* Extra mode bits (Hurd only) */
> __u16 i_uid_high; /* high 16 bits of UID */
> __u16 i_gid_high; /* high 16 bits of GID */
> __u32 i_author; /* Author info (Hurd only) */
>};
I Like this one.
>
>Suggestion 2 is ugly, but some people might like it.
>The layout on disk is exactly the same.
>
....
>
>Looking beyond this: if we get rid of i_dtime and do some bit
>bashing, each of the 3 standard time stamps can get an extra
>high bit (another century) and 20 low bits for microsecond
>resolution. Being less aggressive, we use 2 flag bits and the
>remaining __u32 to give all 4 time stamps an extra high bit
>and 10 low bits for millisecond resolution.
>
>We can mostly ignore time stamps for now. The only concern is
>to not waste the bits we will need. This filesystem is great,
>so it should be extended in a compatible way for many years.
Yes, leave the i_dtime for now.
I think modification of the files in the fs/ext2 directory is
not too difficult. The 2.1.62 and 2.0.31 versions are different,
but not that much. In 2.1.62 the access calls have a loff_t
parameter for position or offset. In 2.0.31 the loff_t f_pos in
struct file is used, and the llseek has a loff_t offset.
For the handling of files other structure are important.
I see problems with:
struct iattr in <linux/fs.h>
off_t ia_size;
struct inode in <linux/fs.h>
off_t i_size;
struct new_stat in <asm/stat.h> (on 32 bits architectures)
unsigned long st_size;
But the struct file in <linux/fs.h> is OK.
loff_t f_pos;
Changing these will have some effect on the other 21 filesystems
I guess? I can not oversee the problems of changes these structs.
Chel