[Bugs] [Bug 1236009] do an explicit lookup on the inodes linked in readdirp

bugzilla at redhat.com bugzilla at redhat.com
Thu Jul 2 09:16:18 UTC 2015


https://bugzilla.redhat.com/show_bug.cgi?id=1236009



--- Comment #1 from Anand Avati <aavati at redhat.com> ---
COMMIT: http://review.gluster.org/11236 committed in master by Niels de Vos
(ndevos at redhat.com) 
------
commit c1a8ae20bd055227921d199b952582eca4104f67
Author: Raghavendra Bhat <raghavendra at redhat.com>
Date:   Fri Jun 12 15:12:05 2015 +0530

    libgfapi: send explicit lookups on inodes linked in readdirp

    If the inode is linked via readdirp, then the consuners of gfapi which are
using
    handles (got either in lookup or readdirp) might not send an explicit
lookup on
    that object again (ex: NFS, samba, USS). If there is a replicate volume
where
    the replicas of the object are not in sync, then readdirp followed by fops
might
    lead data being served from the subvolume which is not in sync with latest
    data. And since lookup is needed to trigger self-heal on that object the
    consumers might keep getting wrong data until an explicit lookup is not
done.

    Fuse handles this situation by sending an explicit lookup by itself (fuse
    xlator) on those inodes which are linked via readdirp, whenever a fop comes
on
    that inode.

    The same procedure is done in gfapi as well to address this situation.

    Thanks to shyam(srangana at redhat.com) for valuable inputs

    Change-Id: I64f0591495dddc1dea7f8dc319f2558a7e342871
    BUG: 1236009
    Signed-off-by: Raghavendra Bhat <raghavendra at redhat.com>
    Reviewed-on: http://review.gluster.org/11236
    Tested-by: NetBSD Build System <jenkins at build.gluster.org>
    Reviewed-by: Shyamsundar Ranganathan <srangana at redhat.com>
    Tested-by: Gluster Build System <jenkins at build.gluster.com>
    Reviewed-by: Niels de Vos <ndevos at redhat.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=EiVcr3aKAD&a=cc_unsubscribe


More information about the Bugs mailing list