Description of problem: NFS does not work properly after upgrading to 3.3. Forcing a self-heal on the entire volume (using a fuse mount) fixes the problem, but may take a long time if there are many files on the volume. Version-Release number of selected component (if applicable): 3.2.6 upgrading to 3.3.0 How reproducible: Always Steps to Reproduce: 1. Create a replicated volume using 3.2.6, and put some files on it. 2. Upgrade to 3.3.0 3. Mount the volume using NFS, stat-ing files does not work (but reading does) 4. Mount the volume using FUSE, and force a self heal on the whole volume (I used find ... | xargs ... stat) 5. NFS mount now works (entries in .glusterfs now created) Actual results: NFS mount is not working after the upgrade. May be time consuming to fix. Expected results: NFS should work right away, or at least the admin should be aware that a self-heal is required first and schedule sufficient time for the operation. Additional info:
bug 842549 is related to this.
Krishna, can you please explain why this is assigned to me again?
(Explained to Amar in person, Amar will take care of the bug)
Will be marking it for Known Issues (and will be closing this bug as WORKSFORME as the work around is available). This work around is better solution as of now, considering the technical issues involved in handling it inside NFS server process itself. Cause: Happens because in 3.2.x versions, there was no concept of gfid based backend, and with 3.3.0, we needed gfid backend. With FUSE mounts we don't have issues as 'lookup()' calls internally handle creating of missing gfids. But on NFS we do have to heal it ourself. Consequence: On NFS, we do experience a short duration of missing files till the self-heal daemon heals all the files. Workaround (if any): Run a full filesystem crawl after the migration on top of FUSE mount. Result: Files will appear on NFS mount also. ---------------- Peter, let me know if this resolution for the bug is fine with you.