Posted Mar 15, 2008 18:39 UTC (Sat) by tialaramex (subscriber, #21167)
Parent article: A better ext4
But, if that field exceeds 32 bits and forces the use of 48-bit numbers, it is thereafter
interpreted as filesystem blocks. Since no existing filesystems are yet using 48-bit numbers,
this approach successfully avoids breaking them.
Reading the patches I can find on LKML this description appears to be wrong.
Instead what's going on is...
* If the file is small enough for a 32-bit sector count, the old 32-bit field is used, the new
16-bit field is set to zero, and the EXT4_HUGE_FILE_FL inode flag is reset if present
* If the file is small enough for a 48-bit sector count, the old 32-bit and new 16-bit field
are used together to store it, and again the EXT4_HUGE_FILE_FL inode flag is reset if present
* If the file is bigger, the count is converted to a block count, stored using both the 32-bit
and 16-bit fields together and the EXT4_HUGE_FILE_FL inode flag is set, as well as a "huge
file" filesystem-wide compatibility flag.
This way of doing things ensures that no previous file could possibly be affected, because the
flag was created for this patch, and without that flag such a colossal file can't be stored on
ext4 at all. It also ensures that older versions of ext4 can't write to a filesystem
containing a huge file they don't understand, and that if they're used to mount the filesystem
read-only, they can't read the affected file (since otherwise they'd find it drastically short
of disk blocks).