Re: [Cluster-devel] [PATCH v7 05/13] fat: make fat_update_time get its own timestamp
OGAWA Hirofumi <[email protected]> Thu, 10 Aug 2023 02:44:10 +0900
| Newsgroups | com.redhat.cluster-devel,dev.linux.lists.ntfs3,dev.linux.lists.ocfs2-devel,dev.linux.lists.v9fs,net.sourceforge.lists.linux-f2fs-devel,org.infradead.lists.linux-mtd,org.kernel.vger.ceph-devel,org.kernel.vger.ecryptfs,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-cifs,org.kernel.vger.linux-ext4,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-nfs,org.kernel.vger.linux-unionfs,org.kernel.vger.linux-xfs,org.kvack.linux-mm,org.ozlabs.lists.linux-erofs |
|---|---|
| Message-ID | <[email protected]> |
Jeff Layton <[email protected]> writes: > On Thu, 2023-08-10 at 00:17 +0900, OGAWA Hirofumi wrote: >> Jan Kara <[email protected]> writes: [...] > My mistake re: lazytime vs. relatime, but Jan is correct that this > shouldn't break anything there. Actually breaks ("break" means not corrupt fs, means it breaks lazytime optimization). It is just not always, but it should be always for some userspaces. > The logic in the revised generic_update_time is different because FAT is > is a bit strange. fat_update_time does extra truncation on the timestamp > that it is handed beyond what timestamp_truncate() does. > fat_truncate_time is called in many different places too, so I don't > feel comfortable making big changes to how that works. > > In the case of generic_update_time, it calls inode_update_timestamps > which returns a mask that shows which timestamps got updated. It then > marks the dirty_flags appropriately for what was actually changed. > > generic_update_time is used across many filesystems so we need to ensure > that it's OK to use even when multigrain timestamps are enabled. Those > haven't been enabled in FAT though, so I didn't bother, and left it to > dirtying the inode in the same way it was before, even though it now > fetches its own timestamps from the clock. Given the way that the mtime > and ctime are smooshed together in FAT, that seemed reasonable. > > Is there a particular case or flag combination you're concerned about > here? Yes. Because FAT has strange timestamps that different granularity on disk . This is why generic time truncation doesn't work for FAT. Well anyway, my concern is the only following part. In generic_update_time(), S_[CM]TIME are not the cause of I_DIRTY_SYNC if lazytime mode. - if ((flags & S_VERSION) && inode_maybe_inc_iversion(inode, false)) + if ((flags & (S_VERSION|S_CTIME|S_MTIME)) && inode_maybe_inc_iversion(inode, false)) dirty_flags |= I_DIRTY_SYNC; If reverted this part to check only S_VERSION, I'm fine. Thanks. -- OGAWA Hirofumi <[email protected]>