[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080429161237.GZ30780@bolzano.suse.de>
Date: Tue, 29 Apr 2008 18:12:37 +0200
From: Jan Blunck <jblunck@...e.de>
To: hooanon05@...oo.co.jp
Cc: bsn.0007@...il.com, libc-alpha@...rceware.org,
Erez Zadok <ezk@...sunysb.edu>, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, viro@...iv.linux.org.uk,
Christoph Hellwig <hch@....de>,
Ulrich Drepper <drepper@...hat.com>,
Mingming Cao <cmm@...ibm.com>,
Dave Hansen <haveblue@...ibm.com>,
Trond Myklebust <trond.myklebust@....uio.no>,
bharata@...ux.vnet.ibm.com, David Woodhouse <dwmw2@...radead.org>
Subject: Re: [RFC PATCH 0/2] Union Mount: Directory listing in glibc
On Wed, Apr 30, hooanon05@...oo.co.jp wrote:
>
> Hello Nagabhushan,
>
> bsn.0007@...il.com:
> > I went through Bharata's RFC post on glibc based Union Mount readdir solution
> > (http://lkml.org/lkml/2008/3/11/34) and have come up with patches
> > against glibc to implement the same.
> :::
>
> While I don't have objection against the implementation in userspace,
> what will UnionMount handle about rmdir or rename dir?
> Those systemcalls need to test whether the dir is *logically* empty or
> not in kernel space, don't they?
> And I am afraid that UnionMount has to implement the similar thing, but
> it never mean to modify glibc is a bad idea.
For rmdir it is simple: the filesystem that supports whiteouts must know how
to get rid of them again. Since it knows how the whiteouts are implemented it
can do that in an optimized fashion.
The rename story is somehow different. A union directory consists of multiple
directories on different filesystem. Since rename syscall is only working on
one filesystem the rename is crossing devices. Therefore I return -EXDEV. Not
very efficient but really simple. At least this is how my patches implement it.
Regards,
Jan
--
Jan Blunck <jblunck@...e.de>
--
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