On Thu, Aug 17, 2017 at 06:23:26PM -0700, Deepa Dinamani wrote: > > I don't think dtime has widened on the disk layout for ext4 according > to https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout. So I am > not sure how fixing the internal implementation would be useful until > we do that. Is there a plan for that? The dtime field is not visible to user; it's mostly for debugging purposes. For debugfs we just are just using i_ctime_extra to compose the time. (Perhaps we should be using i_mtime_extra, or the max of the ctime, mtime, and atime extra fields; but it's not really that important.) The issue which Andreas pointed out is the only place where we actually use the dtime field, and that's so we can avoid re-using a freshly deleted inode until at least N seconds have gone by in no-journal node. That's because if we don't, there are some unfortunate effects that can take place if we crash and not all of the metadata gets updated. Even after running e2fsck -fy, we can end up having a directory or an immutable file show up where ntp or timed expects to find a time adjustment file, or some such, that can cause various system daemons to crash and burn because they aren't expecting find a file at a particular pathname they own which they can't delete. There are a number ways we could solve it; one is to just use a new in-memory variable which can be 64-bits wide. This burns an extra 8 bytes for each inode in the inode cache, which is why we didn't do that. It doesn't really have to be super exact; if we actually have an inode that avoids getting reused for 136 years (2**32 seconds), it will have disappeared from the in-memory inode cache. We just need something which is valid for N seconds after the deletion time. (I think we may have upped N to a larger value on our data center kernels --- 300 seconds if I recall correctly --- because there were some edge cases where 35 seconds wasn't enough.) - Ted
