linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. R. Okajima" <hooanon05@yahoo.co.jp>
To: Michal Suchanek <hramrach@centrum.cz>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	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, jordipujolp@gmail.com,
	ezk@fsl.cs.sunysb.edu
Subject: Re: [PATCH 0/7] overlay filesystem: request for inclusion
Date: Fri, 17 Jun 2011 00:15:53 +0900	[thread overview]
Message-ID: <12737.1308237353@jrobl> (raw)
In-Reply-To: <BANLkTimhL5BG9gHOG0Fr9U5fLkE0NJvpng@mail.gmail.com>


Michal Suchanek:
> Probably swap the two above, you can't make a whiteout in presence of
> the directory, right?
> Anyway, you could just mark dirA as whiteout and remove any whiteouts
> contained in it asynchronously, and only jump through these hoops when
> trying to create a new entry in place of non-empty whiteout, or sync
> on emptying the old whiteout before making a new entry.

Unfortunately I cannot understand what you wrote.

First, the order of
> - create whiteout for dirA
> - rename dirA to .wh..wh.XXXXXXXX
is correct and I think it should be, in order to make a little help for
fsck/auchk.
And what is "non-empty whiteout" and "emptying the old whiteout"?
The whiteout is a size zero-ed and hardlinked regular file in aufs.


> Yes, it can only cause pollution with whiteouts unrelated to any files
> that ever existed which is not too much of an issue unless people want
> to add random stuff to the lower layer and see it in the union when
> they reconstruct it again.

??
Do you think that the .wh..wh.XXXXXXXX hides something on the lower
layer? If so, it is wrong. Such doubly whiteout hides nothing except
itself.


> It is only valid when in the upper layer of a union. However, so is
> whiteout, and so are files that were visible in the union but are not
> visible in the top layer if examined separately, outside of the union.

Do you mean that your special symlink has totally different file-type
from a symlink?
Anyway what I want to say is, what such symlink refers may differ
from what users originally expect. But I may misunderstand what you call
"fallthru symlink".


J. R. Okajima

  reply	other threads:[~2011-06-16 15:15 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
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 [this message]
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=12737.1308237353@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).