[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130528173631.GB2363@lenny.home.zabbo.net>
Date: Tue, 28 May 2013 10:36:31 -0700
From: Zach Brown <zab@...hat.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
viro@...iv.linux.org.uk, torvalds@...ux-foundation.org,
hch@...radead.org, akpm@...ux-foundation.org, dhowells@...hat.com
Subject: Re: [RFC PATCH] vfs: add permute operation
Some quick thoughts:
> Permute the location of files. E.g. 'permute(A, B, C)' is equivalent to A->B,
> B->C and C->A. This is essentially a series of renames done as a single atomic
> operation.
Hmm. Can we choose a more specific name than 'permute'? To me,
->permute() tells me just as much about the operation as
->do_something(). {multi,bulk,mass}_rename()? renamev()?
Maybe it's just me.
> to be done as an atomic operation. We could add whiteout support to filesystem
> ops to perform the creation or removal of whiteouts atomically, but it would
> complicate many filesystem ops needlessly.
>
> Alternatively we can add a generic permute operation and add whiteout support to
> the VFS which utilizes this to perform the operations atomically.
I certainly like the sound of this.
> +static void sort_parents3(struct dentry **p)
> +void sort_parents(struct dentry **p, unsigned *nump)
Yikes, that's a bunch of fiddly code. Is it *really* worth all that to
avoid calling the generic sort helpers?
> + if (WARN_ON(num > PERMUTE_MAX) ||
> + WARN_ON(num < 2))
> + return -EINVAL;
And in other places this is a BUG? Why not, like the syscall, limit the
arguments to three if we're serious about that limitation?
- z
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists