linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. R. Okajima" <hooanon05@yahoo.co.jp>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Valerie Aurora <val@vaaconsulting.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	NeilBrown <neilb@suse.de>,
	viro@ZenIV.linux.org.uk, torvalds@linux-foundation.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	apw@canonical.com, nbd@openwrt.org, hramrach@centrum.cz,
	jordipujolp@gmail.com, ezk@fsl.cs.sunysb.edu
Subject: Re: [PATCH 0/7] overlay filesystem: request for inclusion
Date: Wed, 15 Jun 2011 23:32:56 +0900	[thread overview]
Message-ID: <11186.1308148376@jrobl> (raw)
In-Reply-To: <8739jbjqa7.fsf@tucsk.pomaz.szeredi.hu>


Miklos Szeredi:
> For example "rmdir /ovl/a/b" will do the following:
>
>   1. find the underlying dentry for "a" -> upper-a
>   2. lock upper-a
>   3. find the underlying dentry for "b" -> upper-b
>   4. verify that upper-b is a child of upper-a
>   5. remove upper-b

It is good to verify in step 4.
Essentially (or ideally) this verification should be equivalent to all
of what VFS does before vfs_rmdir(). I know overlayfs makes the upper
mnt_want_write()-ed in early stage and keeps it. So it might be better
to lookup again (as step 3 and 4) instead of comparing d_parent
simply. If you think it is unnecessary to lookup here, then I'd suggest
you to make it option (choosable by user).

I see ovl_rmdir() does,
- lookup and unlink all whiteouts
- rmdir the target dir
- create a whiteout for the target
Right?
But I am afraid that any error can happen in every step on the upper
dir. And if it happens, then ovl_rmdir() returns the error but the dir
left in incomplete status. It may be one of these.
- some whiteouts are unlinked but others are left
- all whiteouts are gone but the target dir remains
- the target dir is removed but the whiteout is not created
Of course, it is bad and makes users really confused, since it will show
users things which should not be. At the same time, I don't know how
possible it can happen.

Anyway if you have read aufs, then you would know how aufs solves these
problems. I don't think the approaches in aufs is best or one and
only. I just could not get another good idea.


J. R. Okajima

  reply	other threads:[~2011-06-15 14:32 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20110609125114.8dff08da.akpm@linux-foundation.org>
2011-06-10  6:57 ` Fw: Re: [PATCH 0/7] overlay filesystem: request for inclusion Valerie Aurora
2011-06-10  9:01   ` Alan Cox
2011-06-15 11:19     ` Miklos Szeredi
2011-06-15 14:32       ` J. R. Okajima [this message]
2011-06-15 15:49         ` Miklos Szeredi
2011-06-15 16:14           ` J. R. Okajima
2011-06-15 17:20             ` Michal Suchanek
2011-06-15 18:12               ` Miklos Szeredi
2011-06-16  2:43               ` J. R. Okajima
2011-06-16 10:35                 ` Michal Suchanek
2011-06-16 15:15                   ` J. R. Okajima
2011-06-17  7:38                     ` Michal Suchanek
2011-06-20  0:43                       ` J. R. Okajima
     [not found]         ` <803fd88dc28748428861b75afdee3575@HUBCAS1.cs.stonybrook.edu>
2011-06-16  0:44           ` Erez Zadok
2011-06-16  3:07             ` J. R. Okajima
2011-06-01 12:46 Miklos Szeredi
2011-06-08 22:32 ` Andrew Morton
2011-06-09  1:59   ` NeilBrown
2011-06-09  3:52     ` Andrew Morton
2011-06-09 12:47       ` Miklos Szeredi
2011-06-09 19:38         ` Andrew Morton
2011-06-09 19:49           ` Felix Fietkau
2011-06-09 22:02           ` Miklos Szeredi
2011-06-10  3:48             ` J. R. Okajima
2011-06-10  9:31               ` Francis Moreau
2011-06-16 18:27                 ` Ric Wheeler
2011-06-10 10:19               ` Michal Suchanek
2011-06-12  7:44                 ` J. R. Okajima
2011-06-13 18:48               ` Miklos Szeredi
2011-07-08 14:44                 ` Miklos Szeredi
2011-07-08 15:21                   ` Tomas M
2011-07-09 12:22                   ` J. R. Okajima
2011-07-15 12:33                     ` Miklos Szeredi
2011-07-15 13:02                       ` J. R. Okajima
2011-07-15 13:04                         ` J. R. Okajima
2011-07-15 13:07                         ` Miklos Szeredi
2011-07-15 13:33                           ` J. R. Okajima
2011-07-15 15:16                             ` Miklos Szeredi
2011-06-09 13:49       ` Andy Whitcroft
2011-06-09 19:32         ` Andrew Morton
2011-06-09 19:40           ` Linus Torvalds
2011-06-09 20:17             ` Miklos Szeredi
2011-06-09 22:58               ` Anton Altaparmakov
2011-06-11  2:39                 ` Greg KH
2011-06-12 20:51                   ` Anton Altaparmakov
2011-06-10 11:51           ` Bernd Schubert
2011-06-10 12:45             ` Michal Suchanek
2011-06-10 12:54               ` Bernd Schubert
2011-06-09 13:57       ` Michal Suchanek
2011-06-09 13:57       ` Andy Whitcroft
2011-07-05 19:54   ` Hans-Peter Jansen
2011-07-08 12:57     ` Miklos Szeredi
2011-07-10  8:23       ` Ric Wheeler
2011-07-10 13:55         ` Sorin Faibish
2011-07-12 15:59           ` Miklos Szeredi
2011-07-10 11:16       ` Hans-Peter Jansen
2011-07-12 16:15         ` Miklos Szeredi
     [not found] ` <4540f7aa16724111bd792a1d577261c2@HUBCAS1.cs.stonybrook.edu>
2011-06-16  6:51   ` Erez Zadok
2011-06-16  9:45     ` Michal Suchanek
2011-06-16 10:45     ` Jordi Pujol
2011-06-16 15:15     ` J. R. Okajima
2011-06-16 16:09       ` Miklos Szeredi
2011-06-16 22:59         ` J. R. Okajima
2011-07-08 14:40         ` Miklos Szeredi
2011-07-09 12:18           ` J. R. Okajima
2011-07-15 10:59             ` Miklos Szeredi
     [not found]     ` <b624059d70d546d4a4ecb940613235ab@HUBCAS2.cs.stonybrook.edu>
     [not found]       ` <BF42D8D9-B947-448A-8818-BCA786E75325@fsl.cs.sunysb.edu>
2011-06-16 23:41         ` J. R. Okajima
     [not found]         ` <ab75a25c918145569b721dea9aea5506@HUBCAS2.cs.stonybrook.edu>
     [not found]           ` <BF19F4F8-9E0F-4983-87C1-BB1B0A11D011@fsl.cs.sunysb.edu>
2011-06-17  1:49             ` J. R. Okajima

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=11186.1308148376@jrobl \
    --to=hooanon05@yahoo.co.jp \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=apw@canonical.com \
    --cc=ezk@fsl.cs.sunysb.edu \
    --cc=hramrach@centrum.cz \
    --cc=jordipujolp@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=nbd@openwrt.org \
    --cc=neilb@suse.de \
    --cc=torvalds@linux-foundation.org \
    --cc=val@vaaconsulting.com \
    --cc=viro@ZenIV.linux.org.uk \
    /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).