lkml.org 
[lkml]   [1998]   [Jan]   [11]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
From"Albert D. Cahalan" <>
SubjectRe: 2G file size limitation question
DateSat, 10 Jan 1998 23:56:53 -0500 (EST)
>> 	__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 */
>> 	__u32	i_size_high;	/* high 32 bits of 64-bit size */
>> 	} u2;
>> 	__u32	i_reserved1;
>> 	__u16	i_reserved2;
> 
> So one can choose either ACLs or 64bit sizes? That's very bad...

Nope, it means _directories_ can't be larger than 4 GB.
Hundreds of millions of files in one directory is not practical
anyway, since searches are linear.

The i_file_acl is not inside the union.

>> /*
>>  * In case people like incompatible change...
>>  * This is cleaner but maybe not worth the trouble.
>>  */
>> struct ext3_inode {
>> 	__u16	i_mode;		/* File mode */
>> 	__u16	i_version;	/* File version (for NFS) */
>> 	__u32	i_flags;	/* File flags */
>> 	__u32	i_gid;		/* Group Id */
>> 	__u32	i_uid;		/* Owner Uid */
>> 	__u32	i_atime;	/* Access time (damn POSIX) */
> If you do this, then several fields should be upgraded, like a/m/ctime to
> __u64, etc.

Since it is not in the standard API, there is not much reason
to waste the space. There are more important things.

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:6.166 / U:0.010 seconds]
©2003-2008 Jasper Spaans