On Thu, Sep 29, 2016 at 7:51 PM, Niels de Vos <ndevos@xxxxxxxxxx> wrote:
Updated the bug from the perspective of AFR as well: https://bugzilla.redhat.com/show_bug.cgi?id=1328581#c12
"I am not sure how an inode which is not in split-brain is linked as 'no read-subvolumes' case. That is something to debug."
Hello,
When NFS-Ganesha does an UNLINK of a filename on an inode, it does a
follow-up check to see if the inode has been deleted or if there are
still other filenames linked (like hardlinks) to it.
Users are getting confused about the errors that are logged by RPC, DHT
and AFR. The file is missing (which is often perfectly expected from a
NFS-Ganesha point of view) and this causes a flood of messages.
>From https://bugzilla.redhat.com/show_bug.cgi?id=1328581#c5 :
> If we reduce the log level for
> client-rpc-fops.c:2974:client3_3_lookup_cbk there would be the
> following entries left:
>
> 2x dht-helper.c:1179:dht_migration_complete_check_task
> 2x afr-read-txn.c:250:afr_read_txn
>
> it would reduce the logging for this non-error with 10 out of 14
> messages. We need to know from the AFR and DHT team if these messages
> are sufficient for them to identify potential issues.
Updated the bug from the perspective of AFR as well: https://bugzilla.redhat.com/show_bug.cgi?id=1328581#c12
"I am not sure how an inode which is not in split-brain is linked as 'no read-subvolumes' case. That is something to debug."
Thanks,
Niels
--
Pranith
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
