From: Jan Kara <jack@suse.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
David Howells <dhowells@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
Kernel Mailing List <linux-kernel@vger.kernel.org>,
Bruce Fields <bfields@fieldses.org>,
Christoph Hellwig <hch@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Zach Brown <zab@redhat.com>, Jan Kara <jack@suse.cz>,
Andy Lutomirski <luto@amacapital.net>,
"mszeredi@suse.cz" <mszeredi@suse.cz>
Subject: Re: [PATCH 00/13] cross rename v4
Date: Wed, 26 Feb 2014 16:15:17 +0100 [thread overview]
Message-ID: <20140226151517.GA11905@quack.suse.cz> (raw)
In-Reply-To: <20140224171238.GG4026@tucsk.piliscsaba.szeredi.hu>
On Mon 24-02-14 18:12:38, Miklos Szeredi wrote:
> On Thu, Feb 13, 2014 at 09:28:50PM +0100, Miklos Szeredi wrote:
> > On Thu, Feb 13, 2014 at 8:32 PM, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
>
> > > (I do think we should allow creation - but for root only - for
> > > management and testing purposes, but I really think it's a secondary
> > > issue, and I do think we should literally use "mknod()" - either with
> > > a new S_IFWHT or even just making use of existing S_IFCHR just so you
> > > could use the user-space "mknod" to create it with some magic
> > > major/minor combination.
> >
> > And IMO the magic S_IFCHR is a lot better in many respects than a new
> > filetype, since now all backup tools automatically work. And I think
> > that's a lot more important than looking like a nice new design.
> > Sure, if S_IFWHT was there from the start, it would be wonderful. But
> > as it stands, it's a lot more difficult to add support for such a
> > thing to userspace than adding a hack, using the existing intefaces,
> > to the kernel.
>
> And here's a patch to actually implement the "rename and whiteout source"
> operation.
>
> Jan, I suspect that the "credits" calculation for the number of journal
> blocks is excessive, since here we don't actually need to create the
> directory entry, only create the inode and populate an already existing
> entry. But I don't undestand the logic of ext4 enough to see what's the
> right number to use here.
Yes. It should be enough to reserve
(EXT4_MAXQUOTAS_TRANS_BLOCKS(sb) + EXT4_XATTR_TRANS_BLOCKS + 4) blocks
(for inode block, sb block, group summaries, and inode bitmap). Please add
this summary to the comment before the estimate.
> And another ext4 specific question: I added ext4_setent(old, whiteout) before
> ext4_add_entry(new, old.inode) because I suspect from the comment in
> ext4_rename_delete() that ext4_add_entry() invalidates the looked up entry. Is
> that correct?
Yes, that is correct. As soon as you add any entry into a directory, any
looked up position in that directory may be invalid (the directory is
implemented as a tree and addition can trigger balancing which moves
things around in the directory).
> Are there any other traps in this area to look out for?
:-) Hum, no I cannot remember any.
Honza
> ----
> Subject: vfs: add RENAME_WHITEOUT
> From: Miklos Szeredi <mszeredi@suse.cz>
>
> This adds a new RENAME_WHITEOUT flag. This flag makes rename() create a
> whiteout of source. The whiteout creation is atomic relative to the
> rename.
>
> As Linus' suggestion, a whiteout is represented as a dummy char device.
> This patch uses the 0/0 device number, but the actual number doesn't matter
> as long as it doesn't conflict with a real device.
>
> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
> ---
> fs/ext4/namei.c | 69 ++++++++++++++++++++++++++++++++++++++----------
> fs/namei.c | 8 ++++-
> include/linux/fs.h | 7 ++++
> include/uapi/linux/fs.h | 1
> 4 files changed, 70 insertions(+), 15 deletions(-)
>
> --- a/fs/ext4/namei.c
> +++ b/fs/ext4/namei.c
> @@ -3157,7 +3157,8 @@ static void ext4_update_dir_count(handle
> * This comes from rename(const char *oldpath, const char *newpath)
> */
> static int ext4_plain_rename(struct inode *old_dir, struct dentry *old_dentry,
> - struct inode *new_dir, struct dentry *new_dentry)
> + struct inode *new_dir, struct dentry *new_dentry,
> + unsigned int flags)
> {
> handle_t *handle = NULL;
> struct ext4_renament old = {
> @@ -3171,6 +3172,9 @@ static int ext4_plain_rename(struct inod
> .inode = new_dentry->d_inode,
> };
> int retval;
> + struct inode *whiteout = NULL;
> + int credits;
> + u8 old_file_type;
>
> dquot_initialize(old.dir);
> dquot_initialize(new.dir);
> @@ -3202,11 +3206,33 @@ static int ext4_plain_rename(struct inod
> if (new.inode && !test_opt(new.dir->i_sb, NO_AUTO_DA_ALLOC))
> ext4_alloc_da_blocks(old.inode);
>
> - handle = ext4_journal_start(old.dir, EXT4_HT_DIR,
> - (2 * EXT4_DATA_TRANS_BLOCKS(old.dir->i_sb) +
> - EXT4_INDEX_EXTRA_TRANS_BLOCKS + 2));
> - if (IS_ERR(handle))
> - return PTR_ERR(handle);
> + credits = (2 * EXT4_DATA_TRANS_BLOCKS(old.dir->i_sb) +
> + EXT4_INDEX_EXTRA_TRANS_BLOCKS + 2);
> + if (!(flags & RENAME_WHITEOUT)) {
> + handle = ext4_journal_start(old.dir, EXT4_HT_DIR, credits);
> + if (IS_ERR(handle))
> + return PTR_ERR(handle);
> + } else {
> + int retries = 0;
> +
> + credits += (EXT4_DATA_TRANS_BLOCKS(old.dir->i_sb) +
> + EXT4_INDEX_EXTRA_TRANS_BLOCKS + 3);
> +retry:
> + whiteout = ext4_new_inode_start_handle(old.dir, S_IFCHR | WHITEOUT_MODE, &old.dentry->d_name, 0, NULL, EXT4_HT_DIR, credits);
> + handle = ext4_journal_current_handle();
> + if (IS_ERR(whiteout)) {
> + if (handle)
> + ext4_journal_stop(handle);
> + retval = PTR_ERR(whiteout);
> + if (retval == -ENOSPC &&
> + ext4_should_retry_alloc(old.dir->i_sb, &retries))
> + goto retry;
> +
> + return retval;
> + }
> + init_special_inode(whiteout, whiteout->i_mode, WHITEOUT_DEV);
> + whiteout->i_op = &ext4_special_inode_operations;
> + }
>
> if (IS_DIRSYNC(old.dir) || IS_DIRSYNC(new.dir))
> ext4_handle_sync(handle);
> @@ -3225,13 +3251,21 @@ static int ext4_plain_rename(struct inod
> if (retval)
> goto end_rename;
> }
> + old_file_type = old.de->file_type;
> + if (whiteout) {
> + retval = ext4_setent(handle, &old, whiteout->i_ino,
> + EXT4_FT_CHRDEV);
> + if (retval)
> + goto end_rename;
> + ext4_mark_inode_dirty(handle, whiteout);
> + }
> if (!new.bh) {
> retval = ext4_add_entry(handle, new.dentry, old.inode);
> if (retval)
> goto end_rename;
> } else {
> retval = ext4_setent(handle, &new,
> - old.inode->i_ino, old.de->file_type);
> + old.inode->i_ino, old_file_type);
> if (retval)
> goto end_rename;
> }
> @@ -3243,10 +3277,12 @@ static int ext4_plain_rename(struct inod
> old.inode->i_ctime = ext4_current_time(old.inode);
> ext4_mark_inode_dirty(handle, old.inode);
>
> - /*
> - * ok, that's it
> - */
> - ext4_rename_delete(handle, &old);
> + if (!whiteout) {
> + /*
> + * ok, that's it
> + */
> + ext4_rename_delete(handle, &old);
> + }
>
> if (new.inode) {
> ext4_dec_count(handle, new.inode);
> @@ -3282,6 +3318,12 @@ static int ext4_plain_rename(struct inod
> brelse(old.dir_bh);
> brelse(old.bh);
> brelse(new.bh);
> + if (whiteout) {
> + if (retval)
> + drop_nlink(whiteout);
> + unlock_new_inode(whiteout);
> + iput(whiteout);
> + }
> if (handle)
> ext4_journal_stop(handle);
> return retval;
> @@ -3407,7 +3449,7 @@ static int ext4_rename(struct inode *old
> struct inode *new_dir, struct dentry *new_dentry,
> unsigned int flags)
> {
> - if (flags & ~(RENAME_NOREPLACE | RENAME_EXCHANGE))
> + if (flags & ~(RENAME_NOREPLACE | RENAME_EXCHANGE | RENAME_WHITEOUT))
> return -EINVAL;
>
> if (flags & RENAME_EXCHANGE) {
> @@ -3418,7 +3460,8 @@ static int ext4_rename(struct inode *old
> * Existence checking was done by the VFS, otherwise "RENAME_NOREPLACE"
> * is equivalent to regular rename.
> */
> - return ext4_plain_rename(old_dir, old_dentry, new_dir, new_dentry);
> + return ext4_plain_rename(old_dir, old_dentry, new_dir, new_dentry,
> + flags);
> }
>
> /*
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -4165,12 +4165,16 @@ SYSCALL_DEFINE5(renameat2, int, olddfd,
> bool should_retry = false;
> int error;
>
> - if (flags & ~(RENAME_NOREPLACE | RENAME_EXCHANGE))
> + if (flags & ~(RENAME_NOREPLACE | RENAME_EXCHANGE | RENAME_WHITEOUT))
> return -EINVAL;
>
> - if ((flags & RENAME_NOREPLACE) && (flags & RENAME_EXCHANGE))
> + if ((flags & (RENAME_NOREPLACE | RENAME_WHITEOUT)) &&
> + (flags & RENAME_EXCHANGE))
> return -EINVAL;
>
> + if ((flags & RENAME_WHITEOUT) && !capable(CAP_MKNOD))
> + return -EPERM;
> +
> retry:
> from = user_path_parent(olddfd, oldname, &oldnd, lookup_flags);
> if (IS_ERR(from)) {
> --- a/include/uapi/linux/fs.h
> +++ b/include/uapi/linux/fs.h
> @@ -37,6 +37,7 @@
>
> #define RENAME_NOREPLACE (1 << 0) /* Don't overwrite target */
> #define RENAME_EXCHANGE (1 << 1) /* Exchange source and dest */
> +#define RENAME_WHITEOUT (1 << 2) /* Whiteout source */
>
> struct fstrim_range {
> __u64 start;
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -215,6 +215,13 @@ typedef void (dio_iodone_t)(struct kiocb
> #define ATTR_TIMES_SET (1 << 16)
>
> /*
> + * Whiteout is represented by a char device. The following constants define the
> + * mode and device number to use.
> + */
> +#define WHITEOUT_MODE 0
> +#define WHITEOUT_DEV 0
> +
> +/*
> * This is the Inode Attributes structure, used for notify_change(). It
> * uses the above definitions as flags, to know which values have changed.
> * Also, in this manner, a Filesystem can look at only the values it cares
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
prev parent reply other threads:[~2014-02-26 15:15 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-07 16:48 [PATCH 00/13] cross rename v4 Miklos Szeredi
2014-02-07 16:48 ` [PATCH 01/13] vfs: add d_is_dir() Miklos Szeredi
2014-02-07 17:36 ` J. Bruce Fields
2014-02-07 19:30 ` David Howells
2014-02-07 16:49 ` [PATCH 02/13] vfs: rename: move d_move() up Miklos Szeredi
2014-02-07 16:49 ` [PATCH 03/13] vfs: rename: use common code for dir and non-dir Miklos Szeredi
2014-02-07 16:49 ` [PATCH 04/13] vfs: add renameat2 syscall Miklos Szeredi
2014-02-07 16:49 ` [PATCH 05/13] vfs: add RENAME_NOREPLACE flag Miklos Szeredi
2014-02-07 16:49 ` [PATCH 06/13] security: add flags to rename hooks Miklos Szeredi
2014-02-07 16:49 ` [PATCH 07/13] vfs: lock_two_nondirectories: allow directory args Miklos Szeredi
2014-02-07 21:16 ` J. Bruce Fields
2014-02-11 15:32 ` Miklos Szeredi
2014-02-07 16:49 ` [PATCH 08/13] vfs: add cross-rename Miklos Szeredi
2014-02-07 22:40 ` J. Bruce Fields
2014-02-11 15:55 ` Miklos Szeredi
2014-02-07 16:49 ` [PATCH 09/13] ext4: rename: create ext4_renament structure for local vars Miklos Szeredi
2014-02-07 16:49 ` [PATCH 10/13] ext4: rename: move EMLINK check up Miklos Szeredi
2014-02-07 16:49 ` [PATCH 11/13] ext4: rename: split out helper functions Miklos Szeredi
2014-02-07 16:49 ` [PATCH 12/13] ext4: add cross rename support Miklos Szeredi
2014-02-11 21:23 ` Jan Kara
2014-02-07 16:49 ` [PATCH 13/13] vfs: merge rename2 into rename Miklos Szeredi
2014-02-07 22:46 ` [PATCH 00/13] cross rename v4 J. Bruce Fields
2014-02-11 15:57 ` Miklos Szeredi
2014-02-13 19:32 ` J. Bruce Fields
2014-02-10 10:51 ` Dave Chinner
2014-02-11 16:01 ` Miklos Szeredi
2014-02-12 17:18 ` Miklos Szeredi
2014-02-17 8:19 ` Dave Chinner
2014-02-17 18:04 ` Theodore Ts'o
2014-03-19 13:57 ` xfstest for renameat2 system call (was: [PATCH 00/13] cross rename v4) Miklos Szeredi
2014-04-08 1:23 ` Dave Chinner
2014-02-13 15:54 ` [PATCH 00/13] cross rename v4 David Howells
2014-02-13 16:25 ` Miklos Szeredi
2014-02-13 16:42 ` David Howells
2014-02-13 17:28 ` Miklos Szeredi
2014-02-13 18:21 ` Andy Lutomirski
2014-02-13 18:29 ` Linus Torvalds
2014-02-13 18:56 ` Miklos Szeredi
2014-02-13 19:20 ` Linus Torvalds
2014-02-13 19:02 ` David Howells
2014-02-13 19:32 ` Linus Torvalds
2014-02-13 20:17 ` Eric W. Biederman
2014-02-13 20:28 ` Miklos Szeredi
2014-02-24 17:12 ` Miklos Szeredi
2014-02-24 17:49 ` Linus Torvalds
2014-02-25 4:07 ` J. R. Okajima
2014-02-26 15:15 ` Jan Kara [this message]
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=20140226151517.GA11905@quack.suse.cz \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=bfields@fieldses.org \
--cc=dhowells@redhat.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=miklos@szeredi.hu \
--cc=mszeredi@suse.cz \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=zab@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).