tree: https://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git
for-next
head: 2a3fda9c1ecf6acd1dbe4bec7b66b4a0503f1586
commit: 226c6235cc2a4ea43e6a73cd8154dc88a3674a84 [7/8] gfs2: Remove
LM_FLAG_PRIORITY flag
config: hexagon-randconfig-r041-20230809
(https://download.01.org/0day
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
This patch adds generic 730 testcase. It will test on various fcntl()
corner cases that was making problems on a GFS2 filesystem. GFS2 has
it's own lock() implementation that has it's own posix lock
implementation behind it. There are testcases to find issues with struct
file_lock matches.
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
Yes. It's in Christian's vfs.ctime branch:
https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/log/?h=vfs.ctime
On Wed, 2023-08-09 at 14:38 -0400, Mike Marshall wrote:
> I've been following this patch on fsdevel... is there a
> remote I could fetch with a branch that has this in it?
>
>
I've been following this patch on fsdevel... is there a
remote I could fetch with a branch that has this in it?
-Mike
On Wed, Aug 9, 2023 at 8:32 AM Christian Brauner wrote:
>
> On Mon, Aug 07, 2023 at 03:38:39PM -0400, Jeff Layton wrote:
> > Now that all of the update_time operations are
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))
> > +
On Mon, Aug 07, 2023 at 03:38:38PM -0400, Jeff Layton wrote:
> In later patches we're going to drop the "now" parameter from the
> update_time operation. Prepare XFS for this by reworking how it fetches
> timestamps and sets them in the inode. Ensure that we update the ctime
> even if only S_MTIME
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 Mon, Aug 07, 2023 at 03:38:39PM -0400, Jeff Layton wrote:
> Now that all of the update_time operations are prepared for it, we can
> drop the timespec64 argument from the update_time operation. Do that and
> remove it from some associated functions like inode_update_time and
>
The last user of this flag was removed in commit b77b4a4815a9 ("gfs2:
Rework freeze / thaw logic").
Signed-off-by: Andreas Gruenbacher
---
Documentation/filesystems/gfs2-glocks.rst | 3 +--
fs/gfs2/glock.c | 22 ++
fs/gfs2/glock.h
Change function do_promote to return true on success, and false
otherwise.
Signed-off-by: Andreas Gruenbacher
---
fs/gfs2/glock.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index 1438e7465e30..d0c82b721f90 100644
---
From: Bob Peterson
Consider the following case:
1. A glock is held in shared mode.
2. A process requests the glock in exclusive mode (rename).
3. Before the lock is granted, more processes (read / ls) request the
glock in shared mode again.
4. gfs2 sends a request to dlm for the lock in
Hi Bob,
On Wed, Jul 26, 2023 at 8:36 PM Bob Peterson wrote:
> I know the description is vague or hard to grasp, but it's hard to be
> succinct for this problem.
as discussed off-list, this one needed a bit more work. I've just
posted the updated version.
Thanks,
Andreas
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 Wed 09-08-23 09:06:34, Christian Brauner wrote:
> On Tue, Aug 08, 2023 at 11:37:01AM +0200, Jan Kara wrote:
> > On Mon 07-08-23 15:38:37, Jeff Layton wrote:
> > > In later patches, we're going to drop the "now" parameter from the
> > > update_time operation. Prepare ubifs for this, by having it
On Mon, 07 Aug 2023 15:38:31 -0400, Jeff Layton wrote:
> The VFS always uses coarse-grained timestamps when updating the
> ctime and mtime after a change. This has the benefit of allowing
> filesystems to optimize away a lot metadata updates, down to around 1
> per jiffy, even when a file is under
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 Tue, Aug 08, 2023 at 11:37:01AM +0200, Jan Kara wrote:
> On Mon 07-08-23 15:38:37, Jeff Layton wrote:
> > In later patches, we're going to drop the "now" parameter from the
> > update_time operation. Prepare ubifs for this, by having it use the new
> > inode_update_timestamps helper.
> >
> >
On Tue, Aug 08, 2023 at 11:39:03AM +0200, Jan Kara wrote:
> On Mon 07-08-23 15:38:38, Jeff Layton wrote:
> > In later patches we're going to drop the "now" parameter from the
> > update_time operation. Prepare XFS for this by reworking how it fetches
> > timestamps and sets them in the inode.
32 matches
Mail list logo
