Re: [PATCH v7 05/13] fat: make fat_update_time get its own timestamp
From: OGAWA Hirofumi
Date: Wed Aug 09 2023 - 18:38:13 EST
Jeff Layton <jlayton@xxxxxxxxxx> writes:
> If you do that then the i_version counter would never be incremented.
> But...I think I see what you're getting at.
>
> Most filesystems that support the i_version counter have an on-disk
> field for it. FAT obviously has no such thing. I suspect the i_version
> bits in fat_update_time were added by mistake. FAT doesn't set
> SB_I_VERSION so there's no need to do anything to the i_version field at
> all.
>
> Also, given that the mtime and ctime are always kept in sync on FAT,
> we're probably fine to have it look something like this:
Yes.
IIRC, when I wrote, I decided to make it keep similar with generic
function, instead of heavily customize for FAT (for maintenance
reason). It is why. There would be other places with same reason.
E.g. LAZYTIME check is same reason too. (current FAT doesn't support it)
So I personally I would prefer to leave it. But if you want to remove
it, it would be ok too.
Thanks.
> --------------------8<------------------
> int fat_update_time(struct inode *inode, int flags)
> {
> int dirty_flags = 0;
>
> if (inode->i_ino == MSDOS_ROOT_INO)
> return 0;
>
> fat_truncate_time(inode, NULL, flags);
> if (inode->i_sb->s_flags & SB_LAZYTIME)
> dirty_flags |= I_DIRTY_TIME;
> else
> dirty_flags |= I_DIRTY_SYNC;
>
> __mark_inode_dirty(inode, dirty_flags);
> return 0;
> }
> --------------------8<------------------
>
> ...and we should probably do that in a separate patch in advance of the
> update_time rework, since it's really a different change.
>
> If you're in agreement, then I'll plan to respin the series with this
> fixed and resend.
>
> Thanks for being patient!
--
OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>