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).
Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds