[Bugs] [Bug 1644322] flooding log with "glusterfs-fuse: read from /dev/fuse returned -1 (Operation not permitted)"

[bugzilla at redhat.com]

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



--- Comment #2 from Christian Lohmaier <lohmaier+rhbz at gmail.com> ---
yes, there is a possibility of it recovering, however never when it manages to
fill up the ~60GB of free disk space on var before - which unfortunately is the
case more often than not.. - if it fills the disk, then also the other
geo-replication sessions go to faulty state.

so if it cannot recover within 10-15 minutes, it likely won't (as the disk is
filled up with the log spam) - I'd say we have it once a week.

Nothing special about system state AFAICT - at least not a ramp-up of resource
usage, if there's anything, it comes and goes in a flash. No effect on rest of
the system, apart from var being full and other geo-replication sessions
suffering from that.

Geo-replication where it occurred last time are in history changelog mode, but
not sure whether that is coincidence

But I think bug#1643716 might be related, as I think it is more likely to
trigger after it failed because of that, i.e. when geo-repliction session keeps
relaunching a gvfs mount / switches from failed to initializing. But that as
well might be a red herring, as the recovery method used so far is to truncate
the logs.... But at least that was the case on the last case where I didn't
throw away the whole log.

The usage pattern on the volume that is geo-replicated is as follows: rsnapshot
creates backups from other hosts via rsync, then those backups are rotated
using hardlinks, in the directories .sync, daily.[0-6], weekly.[0-3] 
i.e. it rsyncs to .sync, then mv daily.6 _delete.$pid; mv daily.5 daily.6
(...); cp -al .sync daily.0; rm -r _delete.$pid

Thus most of the files are hardlinks.

Unfortunately I cannot offer a 100% reliable way to trigger the problem, HTH.

-- 
You are receiving this mail because:
You are on the CC list for the bug.