2020-04-19 1:40 GMT+09:00, Eric Sandeen <sandeen@xxxxxxxxxxx>: > On 4/18/20 11:04 AM, Eric Sandeen wrote: >> since access_time has no corresponding 10msIncrement field, my >> understanding was that it could only have a 2s granularity. > > Maybe your concern is whether the other _time fields should also be > truncated to 2s even though they have the _ms field? I don't think so; the > s_time_gran already limits in-core timestamp resolution to 10ms, which will > be properly translated when the inode is written to disk. > > atime has a different granularity though, so s_time_gran doens't help and > we > must manually change it to 2s whenever we call something like > current_time(), which > only enforces the 10ms granularity. > > So for cases like this: > > generic_fillattr(inode, stat); > + exfat_truncate_atime(&stat->atime); > > or this: > > inode->i_mtime = inode->i_atime = inode->i_ctime = > EXFAT_I(inode)->i_crtime = current_time(inode); > + exfat_truncate_atime(&inode->i_atime); > > I think it's clearly the right thing to do; anything finer than 2s will be > thrown > away when the vfs inode atime is translated to the disk format, so we should > never > hold finer granularity in the in-memory vfs inode. > > However, in exfat_get_entry_time() maybe all we need to do is set > ts->tv_nsec to 0; > that might be clearer. Right. Thanks! > > -Eric >
