From: Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Dave Hansen
<dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Subject: Re: [RFC][PATCH 04/36] btrfs: Add checkpoint file operations
Date: Mon, 4 May 2009 18:06:09 -0700 [thread overview]
Message-ID: <20090505010609.GR11734@us.ibm.com> (raw)
In-Reply-To: <20090504222513.GA32323-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
On Mon, May 04, 2009 at 05:25:13PM -0500, Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
> >
> > Serge E. Hallyn wrote:
> > > Quoting Matt Helsley (matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org):
> > >
> > > ...
> > >
> > >> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> > >> index a7acfe6..f16be9d 100644
> > >> --- a/fs/btrfs/super.c
> > >> +++ b/fs/btrfs/super.c
> > >> @@ -686,6 +686,7 @@ static const struct file_operations btrfs_ctl_fops = {
> > >> .unlocked_ioctl = btrfs_control_ioctl,
> > >> .compat_ioctl = btrfs_control_ioctl,
> > >> .owner = THIS_MODULE,
> > >> + .checkpoint = generic_file_checkpoint,
> > >> };
> > >
> > > Do we really want this one?
> >
> > We need to checkpoint the open file regardless of whether the underlying
> > filesystem has snapshot capabilities.
>
> But maybe we need to refuse a checkpoint if a task is talking to the
> underlying btrfs filesystem?
Good catch. The ctl file is a device node which, as best I can tell, is
empty. So the only obvious concern are the unlocked_ioctl()s. I expect
these ioctls() are "special" so generic_file_checkpoint() is probably
insufficient here.
v2 of the btrfs checkpoint op patch, which removes this hunk, is below.
A non-generic handler which blocks or prevents ioctl() during checkpoint would
seem to be required. Definitely a topic worthy of discussion on linux-fsdevel if
/when we add a .checkpoint op for this.
As best I can tell we don't have anything to handle the generic ioctl() case
either. Am I wrong?
Cheers,
-Matt Helsley
---
Add the checkpoint operation for btrfs files and directories.
Signed-off-by: Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
fs/btrfs/file.c | 1 +
fs/btrfs/inode.c | 1 +
fs/btrfs/super.c | 1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 482f8db..23d5c72 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1334,4 +1334,5 @@ struct file_operations btrfs_file_operations = {
#ifdef CONFIG_COMPAT
.compat_ioctl = btrfs_ioctl,
#endif
+ .checkpoint = generic_file_checkpoint,
};
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 65219f6..583d57e 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -5158,6 +5158,7 @@ static struct file_operations btrfs_dir_file_operations = {
#endif
.release = btrfs_release_file,
.fsync = btrfs_sync_file,
+ .checkpoint = generic_file_checkpoint,
};
static struct extent_io_ops btrfs_extent_io_ops = {
next prev parent reply other threads:[~2009-05-05 1:06 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-04 20:27 [RFC][PATCH 00/36] Add checkpoint file operations Matt Helsley
[not found] ` <63ff4e88102e10e86bffefd5e4445ab433ed51c0.1241462097.git.matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-05-04 20:27 ` [RFC][PATCH 27/36] efs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 22/36] squashfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 13/36] isofs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 17/36] ntfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 09/36] hfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 08/36] freevxfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 16/36] nfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 10/36] hfsplus: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 36/36] hostfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 12/36] hppfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 03/36] bfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 35/36] nilfs2: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 24/36] ubifs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 18/36] openpromfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 04/36] btrfs: " Matt Helsley
[not found] ` <d4c7782efa9f33324f65188dfb480d4ba1af7a27.1241462097.git.matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-05-04 21:41 ` Serge E. Hallyn
[not found] ` <20090504214146.GA31338-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-05-04 22:18 ` Oren Laadan
[not found] ` <49FF69B4.3010700-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2009-05-04 22:25 ` Serge E. Hallyn
[not found] ` <20090504222513.GA32323-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-05-05 1:06 ` Matt Helsley [this message]
2009-05-04 20:27 ` [RFC][PATCH 06/36] ecryptfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 21/36] romfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 15/36] jfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 20/36] reiserfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 14/36] jffs2: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 19/36] qnx4: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 01/36] affs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 25/36] udf: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 30/36] omfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 32/36] ramfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 26/36] xfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 29/36] minix: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 02/36] befs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 23/36] sysv: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 11/36] hpfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 07/36] fat: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 34/36] exofs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 28/36] read_write.c | 1 +: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 31/36] ufs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 33/36] adfs: " Matt Helsley
2009-05-04 20:27 ` [RFC][PATCH 05/36] cramfs: " Matt Helsley
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=20090505010609.GR11734@us.ibm.com \
--to=matthltc-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
/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.