Re: [Gluster-devel] bug (?) that results in busted filesystem info in 2.0.9

[Anand Avati]

On Wed, Feb 3, 2010 at 10:21 PM, Daniel Maher <address@hidden> wrote:
> I have a simple, repeatable scenario that results in the same bug every
> single time.  The setup is very simple :
>
> Four nodes : two clients (Fedora 8) doing client-side replication, and two
> servers (Fedora 9).  All of the nodes are running Gluster 2.0.9. There are
> no performance translators or anything outside of the strict minimum for
> client-side replication.  All of the nodes are connected over Gig-E.
>
> I open two bash sessions on one of the clients.  In both sessions i enter
> the gluster mount point.  In the first session, i create a directory, enter
> that directory, then leave the session open.  In the second session, i
> delete the aforementioned directory, then re-create it.
>
> From the second session's point of view, everything is fine.  The same
> cannot be said the the first session : if i move back a directory to the
> mount point, then run an ls, the (new) directory of the same name is nothing
> but question marks (i.e. timestamp, mode, etc..).  The only solution is
> unmounting and remounting the gluster mount point.
>
> I fully realise that deleting directories that are open is generally bad
> news, but it shouldn't result in busted filesystem info...
>
> Any ideas ?

This is a phenomenon which happens with every FUSE based filesystem
which uses the low-level APIs (high level API based FUSE don't have
this problem but they cannot implement hardlinks and other POSIX
compliances.) There have been discussions about this with FUSE
developers before but I don't think you can expect a solution very
soon. Csaba (CC'ed on this mail) can throw more light on this.

Avati