Plans made now could be incompatible with industry standards in 2038.
We could end up with microseconds since 1970, nanoseconds since 1970,
seconds since 1970, or even Windows NT time stamps.
>> __u32 i_blocks; /* Blocks count */
>
> The number of blocks needs to be higher when we have
> 64-bit sized files.
No, that allows at least 16 TB of real data. At that point, you start
to hit ext2 limits in a big way. Consider the 32-bit block lists
in i_blocks and in the indirect blocks. The whole ext2 filesystem
can not exceed 4 giga-blocks. The triple-indirect limit is exceeded.
You can still have insanely huge sparse files -- though that would
be very bad software design.
We can only reach 16 GB with 1 kB blocks. The triple-indirect blocks
are responsible for the limit until the block size is at least 8 kB,
which Linux does not currently support.
Some of the limits are shown on this graph:
http://www.cs.uml.edu/~acahalan/linux/ext2.gif
>> union {
>> __u32 i_dir_acl; /* Directory ACL (directories only) */
>> __u32 i_size_high; /* high 32 bits of 64-bit size */
>> } u2;
>
> Looks good. Considering how well ext2 scales with large
> directories, we don't really wand >2G directories :-)
We can have 4 GB directories, since the filesystem itself can
still store a 32-bit directory size and the API will be 63-bit.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
