bug (?) that results in busted filesystem info in 2.0.9

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

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 ?


--
Daniel Maher <dma+gluster AT witbe DOT net>




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux