From: Omar Sandoval <osandov-nWWhXC5lh1RBDgjK7y7TUQ@public.gmane.org>
To: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kernel-team-b10kYP2dOMg@public.gmane.org,
Xi Wang <xi-GmWTxIRN22iJaUV4rX00uodd74u8MsAO@public.gmane.org>
Subject: [RFC PATCH v2 0/2] fs: add AT_REPLACE flag for linkat()
Date: Tue, 21 Mar 2017 07:51:46 -0700 [thread overview]
Message-ID: <cover.1490103963.git.osandov@fb.com> (raw)
From: Omar Sandoval <osandov-b10kYP2dOMg@public.gmane.org>
The goal of this series is to allow for updating a file atomically
in-place with an O_TMPFILE like so:
- open temporary file with O_TMPFILE
- write temporary file contents
- fsync temporary file
- atomically replace permanent location with the temporary file
This series implements atomic replace step with a new linkat(..., AT_REPLACE).
Al, I took a look at implementing this usecase with renameat2() after we
talked. Like you said, on the dcache side, "replace with tmpfile" looks
a lot like rename. However, on the filesystem side, trying to use rename
for this is much uglier than using link. We can't give i_op->rename() a
meaningful old_dir, and dealing with that new special case gets messy
fast.
So, here is the approach of having AT_REPLACE just unhash the replaced
dentry.
>From the original cover letter:
This is a proof-of-concept patch series implementing an AT_REPLACE flag for
linkat(2) which allows us to replace the target. This is a nice primitive on
its own, but it's most interesting when combined with O_TMPFILE, as it allows
you to do an atomic update of a file with an O_TMPFILE.
Patch 1 implements the VFS support for this flag. The implementation
resembles sys_renameat2(), and I took care to preserve all of the
original error cases and make the new error cases consistent with
rename.
Patch 2 adds support for AT_REPLACE to Btrfs. That's the codebase I'm
most familiar with so that's where I started, but it should be
straightforward to implement for other filesystems.
Cc: Xi Wang <xi-GmWTxIRN22iJaUV4rX00uodd74u8MsAO@public.gmane.org>
Omar Sandoval (2):
fs: add AT_REPLACE flag for linkat() which replaces the target
Btrfs: add support for linkat() AT_REPLACE
fs/btrfs/inode.c | 65 +++++++++++++++-
fs/ecryptfs/inode.c | 2 +-
fs/namei.c | 181 ++++++++++++++++++++++++++++++++++++---------
fs/nfsd/vfs.c | 2 +-
fs/overlayfs/overlayfs.h | 2 +-
include/linux/fs.h | 3 +-
include/uapi/linux/fcntl.h | 1 +
7 files changed, 211 insertions(+), 45 deletions(-)
--
2.12.0
WARNING: multiple messages have this Message-ID (diff)
From: Omar Sandoval <osandov@osandov.com>
To: Al Viro <viro@zeniv.linux.org.uk>, linux-fsdevel@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-api@vger.kernel.org, kernel-team@fb.com,
Xi Wang <xi@cs.washington.edu>
Subject: [RFC PATCH v2 0/2] fs: add AT_REPLACE flag for linkat()
Date: Tue, 21 Mar 2017 07:51:46 -0700 [thread overview]
Message-ID: <cover.1490103963.git.osandov@fb.com> (raw)
From: Omar Sandoval <osandov@fb.com>
The goal of this series is to allow for updating a file atomically
in-place with an O_TMPFILE like so:
- open temporary file with O_TMPFILE
- write temporary file contents
- fsync temporary file
- atomically replace permanent location with the temporary file
This series implements atomic replace step with a new linkat(..., AT_REPLACE).
Al, I took a look at implementing this usecase with renameat2() after we
talked. Like you said, on the dcache side, "replace with tmpfile" looks
a lot like rename. However, on the filesystem side, trying to use rename
for this is much uglier than using link. We can't give i_op->rename() a
meaningful old_dir, and dealing with that new special case gets messy
fast.
So, here is the approach of having AT_REPLACE just unhash the replaced
dentry.
>From the original cover letter:
This is a proof-of-concept patch series implementing an AT_REPLACE flag for
linkat(2) which allows us to replace the target. This is a nice primitive on
its own, but it's most interesting when combined with O_TMPFILE, as it allows
you to do an atomic update of a file with an O_TMPFILE.
Patch 1 implements the VFS support for this flag. The implementation
resembles sys_renameat2(), and I took care to preserve all of the
original error cases and make the new error cases consistent with
rename.
Patch 2 adds support for AT_REPLACE to Btrfs. That's the codebase I'm
most familiar with so that's where I started, but it should be
straightforward to implement for other filesystems.
Cc: Xi Wang <xi@cs.washington.edu>
Omar Sandoval (2):
fs: add AT_REPLACE flag for linkat() which replaces the target
Btrfs: add support for linkat() AT_REPLACE
fs/btrfs/inode.c | 65 +++++++++++++++-
fs/ecryptfs/inode.c | 2 +-
fs/namei.c | 181 ++++++++++++++++++++++++++++++++++++---------
fs/nfsd/vfs.c | 2 +-
fs/overlayfs/overlayfs.h | 2 +-
include/linux/fs.h | 3 +-
include/uapi/linux/fcntl.h | 1 +
7 files changed, 211 insertions(+), 45 deletions(-)
--
2.12.0
next reply other threads:[~2017-03-21 14:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-21 14:51 Omar Sandoval [this message]
2017-03-21 14:51 ` [RFC PATCH v2 0/2] fs: add AT_REPLACE flag for linkat() Omar Sandoval
[not found] ` <cover.1490103963.git.osandov-b10kYP2dOMg@public.gmane.org>
2017-03-21 14:51 ` [RFC PATCH v2 1/2] fs: add AT_REPLACE flag for linkat() which replaces the target Omar Sandoval
2017-03-21 14:51 ` Omar Sandoval
2017-03-21 16:30 ` Linus Torvalds
[not found] ` <CA+55aFxpzYqt3MYe8Yd7PVVQoPkVpae5diYYBJXh0zu4JCJrYA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-03-21 18:44 ` Omar Sandoval
2017-03-21 18:44 ` Omar Sandoval
2017-03-21 19:02 ` Linus Torvalds
2017-03-21 19:02 ` Linus Torvalds
2017-03-21 20:37 ` Miklos Szeredi
2017-03-21 21:06 ` Linus Torvalds
2017-03-21 14:51 ` [RFC PATCH v2 2/2] Btrfs: add support for linkat() AT_REPLACE Omar Sandoval
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=cover.1490103963.git.osandov@fb.com \
--to=osandov-nwwhxc5lh1rbdgjk7y7tuq@public.gmane.org \
--cc=kernel-team-b10kYP2dOMg@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
--cc=xi-GmWTxIRN22iJaUV4rX00uodd74u8MsAO@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.