Bug 971528

Description of problem:

After a network restart of a gluster client, the gluster fuse mount was in a corrupted state.  ls -la showed listings:

drwxr-s---   3 XXXX XXXX    72 Apr  2 02:00 calbo
?---------   ? ?         ?          ?            ? calbr
drwxr-sr-x   3 XXXX XXXX    72 May 28 02:01 calch
drwxr-s---   3 XXXX XXXX    72 Jun  6 08:28 calgi
?---------   ? ?         ?          ?            ? calhu

The unknown state directories were inaccessible (return non-existent)

The glusterfs logs had entries:

[2013-06-06 05:13:01.669720] W [dht-layout.c:186:dht_layout_search] 0-attachments-dht: no subvolume for hash (value) = 1094163728
[2013-06-06 05:13:01.669732] E [dht-common.c:1372:dht_lookup] 0-attachments-dht: Failed to get hashed subvol for /.emrExternalStore
[2013-06-06 05:13:01.669742] W [fuse-bridge.c:292:fuse_entry_cbk] 0-glusterfs-fuse: 1541616503: LOOKUP() /.emrExternalStore => -1 (Invalid argument)
[2013-06-06 05:13:01.845980] W [dht-layout.c:186:dht_layout_search] 0-attachments-dht: no subvolume for hash (value) = 1094163728
[2013-06-06 05:13:01.846008] E [dht-common.c:1372:dht_lookup] 0-attachments-dht: Failed to get hashed subvol for /.emrExternalStore
[2013-06-06 05:13:01.846024] W [fuse-bridge.c:292:fuse_entry_cbk] 0-glusterfs-fuse: 1541616504: LOOKUP() /.emrExternalStore => -1 (Invalid argument)

Unmounting and remounting the gluster fuse mount restored operation to normal.  However, the question is, why did the gluster fuse mount not handle the network restart gracefully?  (Total time of network outage 20 seconds).

Version-Release number of selected component (if applicable):

3.3.1 for all components

How reproducible:

This happened on a production server.  Cannot reproduce

Steps to Reproduce:
1.
2.
3.

Actual results:

Gluster client got a corrupted mount after a network restart.


Expected results:

Gluster client would restore mount after network restart.


Additional info: