[Gluster-users] writing to fuse device failed: No such file or directory

Fri May 8 06:37:08 UTC 2020

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 at gmail.com>
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.
>
> Sincerely,
> Artem
>
> --
> Founder, Android Police <http://www.androidpolice.com>, APK Mirror
> <http://www.apkmirror.com/>, Illogical Robot LLC
> beerpla.net | @ArtemR <http://twitter.com/ArtemR>
>
>
> On Wed, May 6, 2020 at 2:16 AM Hari Gowtham <hgowtham at redhat.com> 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 <csaba at redhat.com> 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 and
>> then 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 branch
>> and 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 at protonmail.ch> 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 at gmail.com> 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.
>>>
>>> Sincerely,
>>> Artem
>>>
>>> --
>>> Founder, Android Police <http://www.androidpolice.com>, APK Mirror
>>> <http://www.apkmirror.com/>, Illogical Robot LLC
>>> beerpla.net | @ArtemR <http://twitter.com/ArtemR>
>>>
>>>
>>> On Tue, May 5, 2020 at 4:41 AM Hari Gowtham <hgowtham at redhat.com> 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 from
>>>> the older branches to the newer ones (at least release-7 in this case).
>>>>
>>>>
>>>>
>>>> https://review.gluster.org/#/q/change:I510158843e4b1d482bdc496c2e97b1860dc1ba93
>>>>
>>>> On Tue, May 5, 2020 at 11:52 AM mabi <mabi at protonmail.ch> 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 at gmail.com> 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 directory
>>>>>
>>>>> Sincerely,
>>>>> Artem
>>>>>
>>>>> --
>>>>> Founder, Android Police <http://www.androidpolice.com>, APK Mirror
>>>>> <http://www.apkmirror.com/>, Illogical Robot LLC
>>>>> beerpla.net | @ArtemR <http://twitter.com/ArtemR>
>>>>>
>>>>>
>>>>> On Mon, May 4, 2020 at 5:46 AM mabi <mabi at protonmail.ch> 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 at protonmail.ch> 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 UTC
>>>>>> Bridge: https://bluejeans.com/441850968
>>>>>>
>>>>>> Gluster-users mailing list
>>>>>> Gluster-users at gluster.org
>>>>>> https://lists.gluster.org/mailman/listinfo/gluster-users
>>>>>>
>>>>>
>>>>> ________
>>>>>
>>>>>
>>>>>
>>>>> 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 at gluster.org
>>>>> https://lists.gluster.org/mailman/listinfo/gluster-users
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Hari Gowtham.
>>>>
>>>
>>>
>>
>> --
>> Regards,
>> Hari Gowtham.
>>
>

-- 
Regards,
Hari Gowtham.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20200508/19b553bc/attachment.html>