From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Yafang Shao <laoar.shao@gmail.com>,
brauner@kernel.org, jack@suse.cz, linux-fsdevel@vger.kernel.org,
Wangkai <wangkai86@huawei.com>,
Colin Walters <walters@verbum.org>,
Waiman Long <longman@redhat.com>
Subject: Re: [RFC PATCH] fs: dcache: Delete the associated dentry when deleting a file
Date: Sat, 11 May 2024 06:18:07 +0100 [thread overview]
Message-ID: <20240511051807.GA2118490@ZenIV> (raw)
In-Reply-To: <20240511033619.GZ2118490@ZenIV>
On Sat, May 11, 2024 at 04:36:19AM +0100, Al Viro wrote:
> Said that, I seriously suspect that there are loads where it would become
> painful. unlink() + creat() is _not_ a rare sequence, and this would
> shove an extra negative lookup into each of those.
>
> I would like to see the details on original posters' setup. Note that
> successful rmdir() evicts all children, so that it would seem that their
> arseloads of negative dentries come from a bunch of unlinks in surviving
> directories.
>
> It would be interesting to see if using something like
> mkdir graveyard
> rename victim over there, then unlink in new place
> rename next victim over there, then unlink in new place
> ....
> rmdir graveyard
> would change the situation with memory pressure - it would trigger
> eviction of all those negatives at controlled point(s) (rmdir).
> I'm not saying that it's a good mitigation, but it would get more
> details on that memory pressure.
BTW, how about adding to do_vfs_ioctl() something like
case FS_IOC_FORGET:
shrink_dcache_parent(file->f_path.dentry);
return 0;
possibly with option for dropping only negatives?
Even in the minimal form it would allow userland to force eviction
in given directory tree, without disrupting things anywhere else.
That's a trivial (completely untested) patch, really -
diff --git a/fs/ioctl.c b/fs/ioctl.c
index 1d5abfdf0f22..342bb71cf76c 100644
--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -878,6 +878,12 @@ static int do_vfs_ioctl(struct file *filp, unsigned int fd,
case FS_IOC_GETFSSYSFSPATH:
return ioctl_get_fs_sysfs_path(filp, argp);
+ case FS_IOC_FORGET:
+ if (arg != 0) // only 0 for now
+ break;
+ shrink_dcache_parent(filp->f_path.dentry);
+ return 0;
+
default:
if (S_ISREG(inode->i_mode))
return file_ioctl(filp, cmd, argp);
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 45e4e64fd664..143129510289 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -222,6 +222,7 @@ struct fsxattr {
#define FS_IOC_GETFLAGS _IOR('f', 1, long)
#define FS_IOC_SETFLAGS _IOW('f', 2, long)
+#define FS_IOC_FORGET _IOW('f', 255, int)
#define FS_IOC_GETVERSION _IOR('v', 1, long)
#define FS_IOC_SETVERSION _IOW('v', 2, long)
#define FS_IOC_FIEMAP _IOWR('f', 11, struct fiemap)
next prev parent reply other threads:[~2024-05-11 5:18 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-11 2:27 [RFC PATCH] fs: dcache: Delete the associated dentry when deleting a file Yafang Shao
2024-05-11 2:53 ` Linus Torvalds
2024-05-11 3:35 ` Yafang Shao
2024-05-11 4:54 ` Waiman Long
2024-05-11 15:58 ` Matthew Wilcox
2024-05-11 16:07 ` Linus Torvalds
2024-05-11 16:13 ` Linus Torvalds
2024-05-11 18:05 ` Linus Torvalds
2024-05-11 18:26 ` [PATCH] vfs: move dentry shrinking outside the inode lock in 'rmdir()' Linus Torvalds
2024-05-11 18:42 ` Linus Torvalds
2024-05-11 19:28 ` Al Viro
2024-05-11 19:55 ` Linus Torvalds
2024-05-11 20:31 ` Al Viro
2024-05-11 21:17 ` Al Viro
2024-05-12 15:45 ` James Bottomley
2024-05-12 16:16 ` Al Viro
2024-05-12 19:59 ` Linus Torvalds
2024-05-12 20:29 ` Linus Torvalds
2024-05-13 5:31 ` Al Viro
2024-05-13 15:58 ` Linus Torvalds
2024-05-13 16:33 ` Al Viro
2024-05-13 16:44 ` Linus Torvalds
2024-05-23 7:18 ` Dave Chinner
2024-05-11 20:02 ` [PATCH v2] " Linus Torvalds
2024-05-12 3:06 ` Yafang Shao
2024-05-12 3:30 ` Al Viro
2024-05-12 3:36 ` Yafang Shao
2024-05-11 19:24 ` [PATCH] " Al Viro
2024-05-15 2:18 ` [RFC PATCH] fs: dcache: Delete the associated dentry when deleting a file Yafang Shao
2024-05-15 2:36 ` Linus Torvalds
2024-05-15 9:17 ` [PATCH] vfs: " Yafang Shao
2024-05-15 16:05 ` Linus Torvalds
2024-05-16 13:44 ` Oliver Sang
2024-05-22 8:51 ` Oliver Sang
2024-05-23 2:21 ` Yafang Shao
2024-05-22 8:11 ` kernel test robot
2024-05-22 16:00 ` Linus Torvalds
2024-05-22 17:13 ` Matthew Wilcox
2024-05-22 18:11 ` Linus Torvalds
2024-05-11 3:36 ` [RFC PATCH] fs: dcache: " Al Viro
2024-05-11 3:51 ` Yafang Shao
2024-05-11 5:18 ` Al Viro [this message]
2024-05-11 5:32 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240511051807.GA2118490@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=laoar.shao@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=walters@verbum.org \
--cc=wangkai86@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.