Re: 2.1GB File Size Limit

Albert D. Cahalan (acahalan@cs.uml.edu)
Sat, 20 Feb 1999 02:35:15 -0500 (EST)


Alexander Kjeldaas writes:
> On Fri, Feb 19, 1999 at 11:41:01PM -0500, Albert D. Cahalan wrote:
>> Alexander Kjeldaas writes:
>>
>>> with the modification that I use the following stat64 structure
>>> (in linux/include/asm-i386/stat.h). The kernel and glibc have
>>> incompatible structures and instead of translating, I changed the
>>> kernel structure:
>>
>> Don't do that. The glibc people made several mistakes, so they will
>> need to change their struct stat anyway.
>
> I know. It seems a bit broken, but from the glibc-maintainer I was
> told that it was too late to fix this struct.

They changed FILE, which is much more likely to be passed around
between libraries. Perhaps the glibc people were in code freeze.

I get the feeling that they want to dictate Linux kernel structures.
(that whole "GNU project" thing, with Linux being a temporary kernel)

>>> unsigned long st_ino;
>>
>> This is not large enough. Inode numbers must be 64-bit on i386 too.
>> Many filesystems need this, including UDF. Tree-structured filesystems
>> like Reiserfs and XFS work much better with huge inode numbers.
>
> This type is called __ino64_t in glibc 2.1, but is defined to be
> 32-bits wide. I thought it was a typo..

Hmmm, that is weird. Perhaps they tried to change, then gave up when
they had problems.

>>> unsigned long __unused4;
>>> unsigned long __unused5;
>>> };
>>
>> Perhaps this is not enough. Flags, inode version, dtime, author,
>> alternate permission bits... I suggest at least 6 __u32 slots.
>
> Maybe we could sneak in 64-bits for capabilities..

No, that would be a bad idea. It would prevent expansion and waste
space. (very few inodes will have capabilities) The same goes for
ACL data. It would be nice to have a bit to indicate existence though.

I almost mentioned MAC, but I believe that has the same problem.
Compartment lists are variable length, but maybe the level would
not be a problem. (is it one level, or one level per compartment?)
Then again, maybe anyone that wants the level will need to know
the compartments as well.

This looks OK enough:

struct stat64 {
__u64 st_ino; /* why does everyone forget this? */
__u64 st_size;
__u64 st_blocks;
unsigned long st_atime;
unsigned long st_mtime;
unsigned long st_ctime; /* change */
unsigned long __unused0; /* create or delete */
__u32 st_uid;
__u32 st_gid;
__u32 st_blksize;
__u32 st_dev;
__u32 st_rdev;
__u32 st_nlink;
__u16 st_mode;
__u16 __unused1;
__u32 __unused2;
__u64 __unused3;
__u64 __unused4;
__u64 __unused5;
__u64 __unused6;
__u64 __unused7;
};

Then again, maybe time should be stored as (seconds<<24) or (seconds<<32).
Obviously translated as desired by libc.

One could save a bit of space by putting st_rdev and st_size in a union.
This seems to be allowed. In that case, __unused2 should be 64 bits.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/