linux-kernel - Re: [RFC PATCH] vfs: add permute operation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 31 May 2013 00:50:44 +0900
From:	"J. R. Okajima" <hooanon05@...oo.co.jp>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Miklos Szeredi <miklos@...redi.hu>,
	David Howells <dhowells@...hat.com>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux-Fsdevel <linux-fsdevel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Zach Brown <zab@...hat.com>
Subject: Re: [RFC PATCH] vfs: add permute operation

Linus Torvalds:
> On Thu, May 30, 2013 at 5:45 PM, Miklos Szeredi <miklos@...redi.hu> wrote:
> >
> > The third name is because of the replace-empty-directory wart in the
> > rename(2) definition.  With overlay/union that can become
> >
> >  1) check if destination directory is empty:  upper directory contains a
> > whiteout for each lower directory entry and nothing else
> >  2) if empty then remove whiteouts in destination directory
> >  3) and then go on with the normal rename procedure, replacing the empty
> > destination directory with the source directory ,
> >
> > This is done with directory locking, so atomicity is not usually a problem.
> > But in case of a crash between 2) and 3)  we just seriously corrupted the
> > overlay.
> >
> > Suggestions for fixing that?
>
> Why not just do the NFS thing. That has worked forever - using a
> sillyrename as a "pending deletion" instead of actually deleting
> things.
>
> So in between (1) and (2), silly-rename the pseudo-empty target. At
> that point (2) is no longer even an atomicity requirement, because you
> can do the whiteout removal later. In fact, you probably want to do it
> at the end, after doing the "real" rename.

Hmm, where was the quoted Miklos's mail posted? I cannot find it in
both of linux-kernel and linux-fsdevel.

Anyway the idea sounds very similar to the approach which aufs
implemented years ago. Is it?

(from the aufs design document)

Whiteout
----------------------------------------------------------------------
The whiteout in aufs is very similar to Unionfs's. That is represented
by its filename. UnionMount takes an approach of a file mode, but I am
afraid several utilities (find(1) or something) will have to support it.

Basically the whiteout represents "logical deletion" which stops aufs to
lookup further, but also it represents "dir is opaque" which also stop
lookup.

In aufs, rmdir(2) and rename(2) for dir uses whiteout alternatively.
In order to make several functions in a single systemcall to be
revertible, aufs adopts an approach to rename a directory to a temporary
unique whiteouted name.
For example, in rename(2) dir where the target dir already existed, aufs
renames the target dir to a temporary unique whiteouted name before the
actual rename on a branch and then handles other actions (make it opaque,
update the attributes, etc). If an error happens in these actions, aufs
simply renames the whiteouted name back and returns an error. If all are
succeeded, aufs registers a function to remove the whiteouted unique
temporary name completely and asynchronously to the system global
workqueue.

J. R. Okajima
--
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/