Yes, I'm talking about the "writing to fuse device failed:" warning. This is a harmless warning. I have discussed it with Csaba.
I'm not aware of the other messages. If heal messages are one of them, have requested Karthik from the AFR team to look into it.
The rest of the concerns raised are replied in that mail thread. I hope these are all the issues seen with the upgrade to the latest.
On Thu, May 7, 2020 at 1:41 PM Artem Russakovskii <archon810@xxxxxxxxx> wrote:
Hari,Are you talking about "writing to fuse device failed: No such file or directory" or all the messages I've encountered during the 5.13 -> 7.5 upgrade? Because it was more than just logs that went wrong - also healing. Could you please analyze and respond to the relevant thread so we can figure out what went wrong and fix it?Thanks.On Wed, May 6, 2020 at 2:16 AM Hari Gowtham <hgowtham@xxxxxxxxxx> wrote:Hi,We understand the concern about facing a bad migration.Most of this is because of the logging issues.These log messages are harmless and are necessary for debugging purposes.We have just backported the fix to the release branches.This fix will reduce this particular log to debug, so it will be clear that it is not harmful.We will also look into compressing the log messages even more than we do now.Apart from these, to actually make use of this log message for debugging certain issue,we need certain tunings to be done during the mount.@Csaba Henk will let you know the tunings necessary.5.x to 7.x is supported, 5.x to 8.x will not be supported. And we do recommend testing the setup andthen using them for production purposes.Regarding open bugs, Most of the fixes will make its way to the latest releases but might not make it to older releases.And just because it was opened on release-7 doesn't mean the bug is not applicable on release-5 (most of the times)So theoretically newer releases are supposed to be more stable.Most of the times the older branches look stable because of the corner bug which is hit for one user is not applicable for the other.As this bug hasn't been hit for a particular user, doesn't mean they are more stable.All these bugs that we face are backported and fixed in the newer versions, so they are supposed to be even more stable.A few bugs might not be backported to older versions due to various reasons.If you have faced any other major issue with the latest binaries, please do let us know, so we will try to iron them out.It would be great if we could get some help with backporting the patches.Backporting is relatively easy and if the users help with backporting the issues they come across,it will help each other with the fixes being made available for everyone and a more stable release.For a backport, you need to apply the patch from master to the particular release branchand send the patch to the respective branch with the same changeid.One of the reasons this issue (flooding of harmless logs) persisted so long is because we missed to backport.So please do help us.On Wed, May 6, 2020 at 1:16 PM mabi <mabi@xxxxxxxxxxxxx> wrote:Hi everyone,So because upgrading introduces additional problems, does this means I should stick with 5.x even if it is EOL?Or what is a "safe" version to upgrade to?Regards,Mabi‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐On Wednesday, May 6, 2020 2:44 AM, Artem Russakovskii <archon810@xxxxxxxxx> wrote:Hi Hari,Hmm, given how poorly our migration from 5.13 to 7.5 went, I am not sure how I'd move forward with what you suggested at this point.On Tue, May 5, 2020 at 4:41 AM Hari Gowtham <hgowtham@xxxxxxxxxx> wrote:Hi,I don't see the above mentioned fix to be backported to any branch.I have just cherry picked them for the release-6 and 7.Release-5 has reached EOL and so, it won't have the fix.Note: release 6 will have one more release and will be EOLed as well.Release-8 is being worked on and it will have the fix as a part of the way it's branched.Once it gets merged, it should be available in the release-6 and 7. but I do recommend switching fromthe older branches to the newer ones (at least release-7 in this case).On Tue, May 5, 2020 at 11:52 AM mabi <mabi@xxxxxxxxxxxxx> wrote:Dear Artem,Thank you for your answer. If you still see these errors messages with GlusterFS 5.13 I suppose then that this bug fix has not been backported to 5.x.Could someone of the dev team please confirm? It was said on this list that this bug fix would be back ported to 5.x, so I am a bit surprised.Best regards,Mabi‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐On Monday, May 4, 2020 9:57 PM, Artem Russakovskii <archon810@xxxxxxxxx> wrote:I'm on 5.13, and these are the only error messages I'm still seeing (after downgrading from the failed v7 update):[2020-05-04 19:56:29.391121] E [fuse-bridge.c:219:check_and_dump_fuse_W] (--> /usr/lib64/libglusterfs.so.0(_gf_log_callingfn+0x17d)[0x7f0f9a5f324d] (--> /usr/lib64/glusterfs/5.13/xlator/mount/fuse.so(+0x849a)[0x7f0f969d649a] (--> /usr/lib64/glusterfs/5.13/xlator/mount/fuse.so(+0x87bb)[0x7f0f969d67bb] (--> /lib64/libpthread.so.0(+0x84f9)[0x7f0f99b434f9] (--> /lib64/libc.so.6(clone+0x3f)[0x7f0f9987bf2f] ))))) 0-glusterfs-fuse: writing to fuse device failed: No such file or directory[2020-05-04 19:56:29.400541] E [fuse-bridge.c:219:check_and_dump_fuse_W] (--> /usr/lib64/libglusterfs.so.0(_gf_log_callingfn+0x17d)[0x7f0f9a5f324d] (--> /usr/lib64/glusterfs/5.13/xlator/mount/fuse.so(+0x849a)[0x7f0f969d649a] (--> /usr/lib64/glusterfs/5.13/xlator/mount/fuse.so(+0x87bb)[0x7f0f969d67bb] (--> /lib64/libpthread.so.0(+0x84f9)[0x7f0f99b434f9] (--> /lib64/libc.so.6(clone+0x3f)[0x7f0f9987bf2f] ))))) 0-glusterfs-fuse: writing to fuse device failed: No such file or directoryOn Mon, May 4, 2020 at 5:46 AM mabi <mabi@xxxxxxxxxxxxx> wrote:Hello,Now that GlusterFS 5.13 has been released, could someone let me know if this issue (see mail below) has been fixed in 5.13?Thanks and regards,Mabi‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐On Monday, March 2, 2020 3:17 PM, mabi <mabi@xxxxxxxxxxxxx> wrote:> Hello,>> On the FUSE clients of my GlusterFS 5.11 two-node replica+arbitrer I see quite a lot of the following error message repeatedly:>> [2020-03-02 14:12:40.297690] E [fuse-bridge.c:219:check_and_dump_fuse_W] (--> /usr/lib/x86_64-linux-gnu/libglusterfs.so.0(_gf_log_callingfn+0x13e)[0x7f93d5c13cfe] (--> /usr/lib/x86_64-linux-gnu/glusterfs/5.11/xlator/mount/fuse.so(+0x789a)[0x7f93d331989a] (--> /usr/lib/x86_64-linux-gnu/glusterfs/5.11/xlator/mount/fuse.so(+0x7c33)[0x7f93d3319c33] (--> /lib/x86_64-linux-gnu/libpthread.so.0(+0x74a4)[0x7f93d4e8f4a4] (--> /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f93d46ead0f] ))))) 0-glusterfs-fuse: writing to fuse device failed: No such file or directory>> Both the server and clients are Debian 9.>> What exactly does this error message mean? And is it normal? or what should I do to fix that?>> Regards,> Mabi________Community Meeting Calendar:Schedule -Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTCBridge: https://bluejeans.com/441850968Gluster-users mailing list________Community Meeting Calendar:Schedule -Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTCBridge: https://bluejeans.com/441850968Gluster-users mailing list--Regards,Hari Gowtham.
--Regards,
Hari Gowtham.
--
Regards,
Hari Gowtham.
Hari Gowtham.
________ Community Meeting Calendar: Schedule - Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC Bridge: https://bluejeans.com/441850968 Gluster-users mailing list Gluster-users@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-users
