be interested in this article too:
https://lwn.net/Articles/752613/
Neil points out in the comments that issuing a close() doesn't
necessarily initiate any writeback from the kernel. It does on NFS of
course, but not on most filesystems.
So, a successful return from close() is inconclusive. It just means
that the kernel has not hit a writeback error yet, not that the data is
truly safe.
--
Jeff Layton
erspace to kernel (now Jeff in CC will hopefully clarify this)
>
The POSIX<->NFSv4 ACL translation has always been in the kernel server.
It has to be, as the primary purpose is to translate v4 ACLs from the
clients to and from the POSIX ACLs that the exported Linux filesystems
support.
--
Jeff Layton
On Mon, 2023-05-15 at 17:28 +, Trond Myklebust wrote:
> On Mon, 2023-05-15 at 13:11 -0400, Jeff Layton wrote:
> > On Mon, 2023-05-15 at 11:50 +, Ondrej Valousek wrote:
> > > Hi Paul,
> > >
> > > Ok first of all, thanks for taking initiative on this, I a
On Tue, 2023-05-16 at 11:17 +0200, Christian Brauner wrote:
> On Mon, May 15, 2023 at 01:49:21PM -0400, Jeff Layton wrote:
> > On Mon, 2023-05-15 at 17:28 +, Trond Myklebust wrote:
> > > On Mon, 2023-05-15 at 13:11 -0400, Jeff Layton wrote:
> > > > On Mon, 202
On Tue, 2023-09-19 at 13:04 +0200, Jan Kara wrote:
> On Tue 19-09-23 15:05:24, Xi Ruoyao wrote:
> > On Mon, 2023-08-07 at 15:38 -0400, Jeff Layton wrote:
> > > Enable multigrain timestamps, which should ensure that there is an
> > > apparent change to the timestamp w
On Tue, 2023-09-19 at 16:52 +0200, Bruno Haible wrote:
> Jeff Layton wrote:
> > I'm not sure what we can do for this test. The nap() function is making
> > an assumption that the timestamp granularity will be constant, and that
> > isn't necessarily the case now.
On Tue, 2023-09-19 at 13:10 -0700, Paul Eggert wrote:
> On 2023-09-19 09:31, Jeff Layton wrote:
> > The typical case for make
> > timestamp comparisons is comparing source files vs. a build target. If
> > those are being written nearly simultaneously, then that could be an
>
Directory modifications are
> synchronous */
> #define SB_NOATIME BIT(10) /* Do not update access times. */
> @@ -2105,6 +2106,7 @@ static inline bool sb_rdonly(const struct super_block
> *sb) { return sb->s_flags
> ((inode)->i_flags & (S_SYNC|S_DIRSYNC)))
> #define IS_MANDLOCK(inode) __IS_FLG(inode, SB_MANDLOCK)
> #define IS_NOATIME(inode)__IS_FLG(inode, SB_RDONLY|SB_NOATIME)
> +#define IS_MGTIME(inode) __IS_FLG(inode, SB_MGTIME)
> #define IS_I_VERSION(inode) __IS_FLG(inode, SB_I_VERSION)
>
>
> #define IS_NOQUOTA(inode)((inode)->i_flags & S_NOQUOTA)
> @@ -2366,7 +2368,7 @@ struct file_system_type {
> */
> static inline bool is_mgtime(const struct inode *inode)
> {
> - return inode->i_sb->s_type->fs_flags & FS_MGTIME;
> + return inode->i_sb->s_flags & SB_MGTIME;
> }
>
>
> extern struct dentry *mount_bdev(struct file_system_type *fs_type,
The mount option looks reasonable. Thanks for throwing together the
patch. Maybe in the future we can come up with a way to mitigate the
problems and do this unconditionally?
Reviewed-by: Jeff Layton
request_mask, inode);
> > } else {
> > stat->mtime = inode->i_mtime;
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index 4aeb3fa11927..03e415fb3a7c 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -1114,6 +1114,7 @@ extern int send_sigurg(struct fown_struct *fown);
> > #define SB_NODEVBIT(2) /* Disallow access to device special
> > files */
> > #define SB_NOEXEC BIT(3) /* Disallow program execution */
> > #define SB_SYNCHRONOUS BIT(4) /* Writes are synced at once */
> > +#define SB_MGTIME BIT(5) /* Use multi-grain timestamps */
> > #define SB_MANDLOCK BIT(6) /* Allow mandatory locks on an FS */
> > #define SB_DIRSYNC BIT(7) /* Directory modifications are
> > synchronous */
> > #define SB_NOATIME BIT(10)/* Do not update access times. */
> > @@ -2105,6 +2106,7 @@ static inline bool sb_rdonly(const struct super_block
> > *sb) { return sb->s_flags
> > ((inode)->i_flags & (S_SYNC|S_DIRSYNC)))
> > #define IS_MANDLOCK(inode) __IS_FLG(inode, SB_MANDLOCK)
> > #define IS_NOATIME(inode) __IS_FLG(inode, SB_RDONLY|SB_NOATIME)
> > +#define IS_MGTIME(inode) __IS_FLG(inode, SB_MGTIME)
> > #define IS_I_VERSION(inode)__IS_FLG(inode, SB_I_VERSION)
> >
> > #define IS_NOQUOTA(inode) ((inode)->i_flags & S_NOQUOTA)
> > @@ -2366,7 +2368,7 @@ struct file_system_type {
> > */
> > static inline bool is_mgtime(const struct inode *inode)
> > {
> > - return inode->i_sb->s_type->fs_flags & FS_MGTIME;
> > + return inode->i_sb->s_flags & SB_MGTIME;
> > }
> >
> > extern struct dentry *mount_bdev(struct file_system_type *fs_type,
> > --
> > 2.34.1
> >
--
Jeff Layton
#x27;t a big deal regressions like this were always to be expected but
> v6.6 needs to stabilize so anything that requires more significant work
> is not an option.
Oh, absolutely.
I wasn't proposing to do that work for v6.6. For that, we absolutely
either need the mount option or to just revert the mgtime conversions.
My plan was to take a stab at doing this for a later kernel release.
This is very much a "back to the drawing board" idea. It may not pan out
after all, but if it does then we could consider removing the mount
option at that point.
--
Jeff Layton
; @Jan, what do you think?
>
> > My plan was to take a stab at doing this for a later kernel release.
>
> Ok.
If it works out, then we may be able to eventually remove the mount
option, but that is a separate project altogether.
--
Jeff Layton
On Wed, 2023-09-20 at 14:48 +0200, Jan Kara wrote:
> On Wed 20-09-23 06:35:18, Jeff Layton wrote:
> > On Wed, 2023-09-20 at 12:17 +0200, Jan Kara wrote:
> > > If I were a sysadmin, I'd rather opt for something like
> > > finegrained timestamps + lazytime (if I n
need some time to
ponder the options for this series anyway, and another cycle in next
wouldn't hurt.
The branch itself looks fine, but you might want to reverse the order of
the patches in case someone lands there in the middle of a bisect. IOW,
I think you want to revert the "convert to multigrain" patches before
you revert the infrastructure.
--
Jeff Layton
coarse-grained timer tick from that.
[1]:
https://lore.kernel.org/linux-fsdevel/20240626-mgtime-v1-0-a189352d0...@kernel.org/
Signed-off-by: Jeff Layton
---
Failure of the test-stat-time test is what triggered us to revert the
multigrain timestamp series from the Linux kernel last October. With
On Sat, 2024-06-29 at 03:33 +0200, Bruno Haible wrote:
> Jeff Layton wrote:
> > Failure of the test-stat-time test is what triggered us to revert the
> > multigrain timestamp series from the Linux kernel last October. With
> > that failure, we'd sometimes see time
to test before that, the patches are in the "mgtime" branch
of my public tree:
https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
...but you'll have to build your own kernel for that.
--
Jeff Layton
e patches are in the "mgtime" branch
> > of my public tree:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
> >
> > ...but you'll have to build your own kernel for that.
>
> Good to know, but I'll abstain from that, since I haven't successfully
> built a working custom kernel in a long time.
>
> Bruno
>
>
>
--
Jeff Layton
> > of my public tree:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git/
> >
> > ...but you'll have to build your own kernel for that.
>
> Good to know, but I'll abstain from that, since I haven't successfully
> built a working custom kernel in a long time.
>
> Bruno
>
>
>
--
Jeff Layton
18 matches
Mail list logo
