Unfortunately, it looks like the exact error text has already rolled off my logs. Earlier today something jammed up and I restarted ceph, which returned everything to a healthy state. But I'll take that as an indicator that ceph isn't a good match for sleeper systems. Fortunately, ganesha NFS is now working properly for me since I upgraded Octopus to Pacific and I no longer feel the need for a direct mount. NFS has had to deal with hibernation for years, so I think I can depend on it to deal with it one way or the other. Tim On Tue, 2024-02-06 at 13:00 -0500, Patrick Donnelly wrote:
On Tue, Feb 6, 2024 at 12:09 PM Tim Holloway <timh@mousetech.com> wrote:
Back when I was battline Octopus, I had problems getting ganesha's NFS to work reliably. I resolved this by doing a direct (ceph) mount on my desktop machine instead of an NFS mount.
I've since been plagued by ceph "laggy OSD" complaints that appear to be due to a non-responsive client and I'm suspecting that the client in question is the desktop machine when it's suspended while the ceph mount is in effect.
You should not see "laggy OSD" messages due to a client becoming unresponsive.
So the question is: Should ceph native mounts be used on general client machines which may hibernate or otherwise go offline?
The mounts will eventually be evicted (generally) by the MDS if the machine hibernates/suspends. There are mechanisms for the mount to recover (see "recover_session" in the mount.ceph man page). Any dirty data would be lost.
As for whether you should have clients that hibernate, it's not ideal. It could conceivably create problems if client machines hibernate longer than the blocklist duration (after eviction by the MDS).
-- Patrick Donnelly, Ph.D. He / Him / His Red Hat Partner Engineer IBM, Inc. GPG: 19F28A586F808C2402351B93C3301A3E258DD79D _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io