On 2011-06-10, at 2:27 AM, Akira Fujita <a-fujita@xxxxxxxxxxxxx> wrote: > > Officially, ext4 can handle its timestamps until 2514 > with 32bit entries plus EPOCH_BIT (2bits). > But when timestamps values use 32+ bit > (e.g. 2038-01-19 9:14:08 0x0000000080000000), > we can get corrupted values. > Because sign bit is overwritten by transferring value > between kernel space and user space. > > This can be happened with kernel 3.0.0-rc2 (Also older kernel) > on x86_64. > > # This issue is already on Bugzilla, > does anybody know this current status? > https://bugzilla.kernel.org/show_bug.cgi?id=23732 I can't find any discussion about this bug in the list archives, but it is definitely a real problem. At first glance, it appears that the correct solution is to shift the high bits in the extra time by only 31 bits. As stated in the posting, it makes sense to keep the range -2^31 - +2^33 for maximum usability. I don't think there is any value to store more negative times. To be honest I also don't think there is any value to even keeping negative timestamps (before 1970) since this is about storing file creation or modification times and I don't think any files with real creation dates before 1970 are used anywhere. Either way I expect the time range to be sufficient, once the bug is fixed. > Reproduce steps are as follows: > # System time is set to UTC. > > # mount -t ext4 /dev/sda8 /mnt/mp1 > > # touch -t 203801190314.08 /mnt/mp1/FILE > > # umount /mnt/mp1 > # mount -t ext4 /dev/sda8 /mnt/mp1 > > # stat /mnt/mp1/FILE > File: `/mnt/mp1/FILE' > Size: 0 Blocks: 0 IO Block: 4096 regular empty file > Device: 808h/2056d Inode: 12 Links: 1 > Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) > Access: 1901-12-13 20:45:52.000000000 +0000 <----- > Modify: 1901-12-13 20:45:52.000000000 +0000 <----- > Change: 2011-06-10 03:57:39.595385951 +0100 > Birth: - Hmm, interesting, I wonder how stat is expecting to get the "Birth" time from the kernel? We have the crtime in ext4 inodes, so we could be returning it. Cheers, Andreas-- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
