From: Al Viro <viro@ZenIV.linux.org.uk>
To: George Spelvin <linux@horizon.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
miklos@szeredi.hu
Subject: Re: [PATCH 00/13] overlay filesystem: request for inclusion (v16)
Date: Wed, 20 Mar 2013 21:32:05 +0000 [thread overview]
Message-ID: <20130320213205.GR21522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20130320194108.24192.qmail@science.horizon.com>
On Wed, Mar 20, 2013 at 03:41:08PM -0400, George Spelvin wrote:
> Sorry for being so very late to the party, but rather than messing
> with xattrs, why not just have a specific file (say, default /.whiteout,
> but selectable via a mount option) and links to it are counted as
> whiteout entries?
>
> All you need to do is resolve the link (it's probably a good idea
> to allow symlinks to avoid hard-link count limits) and compare the
> fs and inode number.
>
> It's kind of hackish, but it could be done on pretty much *any* Unix
> file system. VFAT would be SOL, but that's probably acceptable.
>
> (Any security options on mount point crossing or consistent ownership
> of symlinks that you want to impose would probably be of general VFS
> use, and again, not FS-specific.)
Yeah... Now, think what rm -rf foo/ would be doing. We read the
underlying directory. For each file in it we create a link to that
magical file of yours in covering one. _Then_ we do rmdir(), and what a joy
it turns out to be - we
* lock the covering directory
* read the covering directory and stat everything in it, checking that
it's a link to your file; we also read the underlying directory and verify
that everything in it has a matching whiteout in the covering one.
* once we are through, we read it *again*, this time doing unlinks
and praying real hard we won't crash in the meanwhile
* once that is finished, we finally can rmdir the fucker and unlock
its inode.
I'm sorry, but this is insane.
next prev parent reply other threads:[~2013-03-20 21:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-20 19:41 [PATCH 00/13] overlay filesystem: request for inclusion (v16) George Spelvin
2013-03-20 21:32 ` Al Viro [this message]
2013-03-22 5:15 ` Rob Landley
-- strict thread matches above, loose matches on Subject: below --
2013-03-12 15:41 Miklos Szeredi
2013-03-12 16:49 ` Sedat Dilek
2013-03-12 20:00 ` Miklos Szeredi
2013-03-12 17:22 ` J. R. Okajima
2013-03-12 20:01 ` Miklos Szeredi
2013-03-12 21:50 ` Linus Torvalds
2013-03-12 22:23 ` Al Viro
2013-03-13 9:42 ` Sedat Dilek
2013-03-13 15:24 ` Miklos Szeredi
2013-03-13 18:52 ` Al Viro
2013-03-13 22:09 ` Miklos Szeredi
2013-03-13 23:19 ` Al Viro
2013-03-14 10:37 ` Miklos Szeredi
2013-03-14 22:59 ` Al Viro
2013-03-18 11:27 ` Miklos Szeredi
2013-03-13 10:09 ` Sedat Dilek
2013-03-13 10:57 ` Miklos Szeredi
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=20130320213205.GR21522@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.com \
--cc=miklos@szeredi.hu \
/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.