Thread (2 messages) 2 messages, 2 authors, 2023-08-09

Re: [PATCH v7 05/13] fat: make fat_update_time get its own timestamp

From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date: 2023-08-09 18:31:46
Also in: ceph-devel, linux-btrfs, linux-cifs, linux-f2fs-devel, linux-fsdevel, linux-mm, linux-nfs, linux-unionfs, linux-xfs, lkml, ntfs3, ocfs2-devel, v9fs

Jeff Layton [off-list ref] writes:
On Thu, 2023-08-10 at 02:44 +0900, OGAWA Hirofumi wrote:
quoted
Jeff Layton [off-list ref] writes:
That would be wrong. The problem is that we're changing how update_time
works:

Previously, update_time was given a timestamp and a set of S_* flags to
indicate which fields should be updated. Now, update_time is not given a
timestamp. It needs to fetch it itself, but that subtly changes the
meaning of the flags field.

It now means "these fields needed to be updated when I last checked".
The timestamp and i_version may now be different from when the flags
field was set. This means that if any of S_CTIME/S_MTIME/S_VERSION were
set that we need to attempt to update all 3 of them. They may now be
different from the timestamp or version that we ultimately end up with.

The above may look to you like it would always cause I_DIRTY_SYNC to be
set on any ctime or mtime update, but inode_maybe_inc_iversion only
returns true if it actually updated i_version, and it only does that if
someone issued a ->getattr against the file since the last time it was
updated.

So, this shouldn't generate any more DIRTY_SYNC updates than it did
before.
Again, if you claim so, why generic_update_time() doesn't work same? Why
only FAT does?

Or I'm misreading generic_update_time() patch?

Thanks.
-- 
OGAWA Hirofumi [off-list ref]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help