Jeff Layton 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
On Thu, 2023-08-10 at 05:14 +0900, OGAWA Hirofumi wrote:
> Jeff Layton writes:
>
> > When you say it "doesn't work the same", what do you mean, specifically?
> > I had to make some allowances for the fact that FAT is substantially
> > different in its timestamp handling, and I tried to preserve
Jeff Layton writes:
> When you say it "doesn't work the same", what do you mean, specifically?
> I had to make some allowances for the fact that FAT is substantially
> different in its timestamp handling, and I tried to preserve existing
> behavior as best I could.
Ah, ok. I was misreading
On Thu, 2023-08-10 at 03:31 +0900, OGAWA Hirofumi wrote:
> Jeff Layton writes:
>
> > On Thu, 2023-08-10 at 02:44 +0900, OGAWA Hirofumi wrote:
> > > Jeff Layton writes:
> > >
> > That would be wrong. The problem is that we're changing how update_time
> > works:
> >
> > Previously, update_time
Jeff Layton writes:
> On Thu, 2023-08-10 at 02:44 +0900, OGAWA Hirofumi wrote:
>> Jeff Layton 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
On Thu, 2023-08-10 at 02:44 +0900, OGAWA Hirofumi wrote:
> Jeff Layton writes:
>
> > On Thu, 2023-08-10 at 00:17 +0900, OGAWA Hirofumi wrote:
> > > Jan Kara writes:
>
> [...]
>
> > My mistake re: lazytime vs. relatime, but Jan is correct that this
> > shouldn't break anything there.
>
>
Jeff Layton writes:
> On Thu, 2023-08-10 at 00:17 +0900, OGAWA Hirofumi wrote:
>> Jan Kara 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
On Thu, 2023-08-10 at 00:17 +0900, OGAWA Hirofumi wrote:
> Jan Kara writes:
>
> > Since you are talking past one another with Jeff let me chime in here :). I
> > think you are worried about this hunk:
>
> Right.
>
> > - if ((flags & S_VERSION) && inode_maybe_inc_iversion(inode, false))
> > +
Jan Kara writes:
> Since you are talking past one another with Jeff let me chime in here :). I
> think you are worried about this hunk:
Right.
> - if ((flags & S_VERSION) && inode_maybe_inc_iversion(inode, false))
> + if ((flags & (S_VERSION|S_CTIME|S_MTIME)) &&
>
On Wed 09-08-23 22:36:29, OGAWA Hirofumi wrote:
> Jeff Layton writes:
>
> > On Wed, 2023-08-09 at 17:37 +0900, OGAWA Hirofumi wrote:
> >> Jeff Layton writes:
> >>
> >> > Also, it may be that things have changed by the time we get to calling
> >> > fat_update_time after checking
OGAWA Hirofumi writes:
> Jeff Layton writes:
>
>> I'm a little confused too. Why do you believe this will break
>> -o relatime handling? This patch changes two things:
>>
>> 1/ it has fat_update_time fetch its own timestamp (and ignore the "now"
>> parameter). This is in line with the changes
Jeff Layton writes:
> I'm a little confused too. Why do you believe this will break
> -o relatime handling? This patch changes two things:
>
> 1/ it has fat_update_time fetch its own timestamp (and ignore the "now"
> parameter). This is in line with the changes in patch #3 of this series,
>
On Wed, 2023-08-09 at 22:36 +0900, OGAWA Hirofumi wrote:
> Jeff Layton writes:
>
> > On Wed, 2023-08-09 at 17:37 +0900, OGAWA Hirofumi wrote:
> > > Jeff Layton writes:
> > >
> > > > Also, it may be that things have changed by the time we get to calling
> > > > fat_update_time after checking
Jeff Layton writes:
> On Wed, 2023-08-09 at 17:37 +0900, OGAWA Hirofumi wrote:
>> Jeff Layton writes:
>>
>> > Also, it may be that things have changed by the time we get to calling
>> > fat_update_time after checking inode_needs_update_time. Ensure that we
>> > attempt the i_version bump if
On Wed, 2023-08-09 at 17:37 +0900, OGAWA Hirofumi wrote:
> Jeff Layton writes:
>
> > Also, it may be that things have changed by the time we get to calling
> > fat_update_time after checking inode_needs_update_time. Ensure that we
> > attempt the i_version bump if any of the S_* flags besides
Jeff Layton writes:
> Also, it may be that things have changed by the time we get to calling
> fat_update_time after checking inode_needs_update_time. Ensure that we
> attempt the i_version bump if any of the S_* flags besides S_ATIME are
> set.
I'm not sure what it meaning though, this is from
OGAWA Hirofumi writes:
> Jeff Layton writes:
>
>> Also, it may be that things have changed by the time we get to calling
>> fat_update_time after checking inode_needs_update_time. Ensure that we
>> attempt the i_version bump if any of the S_* flags besides S_ATIME are
>> set.
>
> I'm not sure
On Tue, Aug 08, 2023 at 11:32:26AM +0200, Jan Kara wrote:
> On Mon 07-08-23 15:38:36, Jeff Layton wrote:
> > In later patches, we're going to drop the "now" parameter from the
> > update_time operation. Fix fat_update_time to fetch its own timestamp.
> > It turns out that this is easily done by
On Mon 07-08-23 15:38:36, Jeff Layton wrote:
> In later patches, we're going to drop the "now" parameter from the
> update_time operation. Fix fat_update_time to fetch its own timestamp.
> It turns out that this is easily done by just passing a NULL timestamp
> pointer to fat_update_time.
In later patches, we're going to drop the "now" parameter from the
update_time operation. Fix fat_update_time to fetch its own timestamp.
It turns out that this is easily done by just passing a NULL timestamp
pointer to fat_update_time.
Also, it may be that things have changed by the time we get
20 matches
Mail list logo
