On Mon, Jun 02, 2014 at 02:38:09PM +0200, Arnd Bergmann wrote: > > "For new inodes we always reserve enough space for the kernel's known > extended fields, but for inodes created with an old kernel this might > not have been the case. None of the extended inode fields is critical > for correct filesystem operation." > > Do we have to worry about this for inodes that contain extended > attributes and that get updated after 2038? In practice, the extended timestamps was one of the first things added to ext4, so the vast majority of ext4 file systems with inode sizes > 128 bytes will have room for the extended timestamps. There are some legacy ext3 file systems with 256-byte inodes (enabled for fast sotrage of SELinux xattrs) that in theory, could have been converted to ext4 and had enough xattrs so that the extended timestamps couldn't be added. That would be a vanishingly small use case, and in practice, it's not likely to be the case for the embedded market. I could imagine someone worrying about file systems originally formatted using RHEL 4 post-2038 (perhaps running in a VM), but I don't work for IBM any more, and hopefully even IBM would just tell such customers that they need to suck it up, and do a backup/reformat/restore pass. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
