[lkml]   [1997]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Filesize limitation
"Albert D. Cahalan" <> wote:
>> The nice thing about ext2 is that it is available for
>> Linux/Masix/Hurd; I think it would be foolish to add support for
>> larger files to the Linux port, when this would make it
>> incompatible with the other OSs that use ext2.
>If it would be incompatible, maybe. It's not incompatible
>though, so you can continue to pretend that there are other
>useful OSs that run native on ext2.

I think your proposal is compatible with these known

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


 \ /
  Last update: 2005-03-22 13:40    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site