All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolaus Rath <Nikolaus@rath.org>
To: Bernd Schubert <bernd.schubert@fastmail.fm>
Cc: nbd@other.debian.org,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	miklos <mszeredi@redhat.com>, Wouter Verhelst <w@uter.be>
Subject: Re: Why do NBD requests prevent hibernation, and FUSE requests do not?
Date: Wed, 07 Sep 2022 16:50:17 +0100	[thread overview]
Message-ID: <87zgfbqj46.fsf@vostro.rath.org> (raw)
In-Reply-To: <f7110017-8606-8e50-7d86-fc53324a571d@fastmail.fm> (Bernd Schubert's message of "Wed, 31 Aug 2022 01:02:16 +0200")

On Aug 31 2022, Bernd Schubert <bernd.schubert@fastmail.fm> wrote:
> On 8/30/22 08:31, Nikolaus Rath wrote:
>> Hello,
>> I am comparing the behavior of FUSE and NBD when attempting to hibernate
>> the system.
>> FUSE seems to be mostly compatible, I am able to suspend the system even
>> when there is ongoing I/O on the fuse filesystem.
>> 
>
> ....
>
>> As far as I can tell, the problem is that while an NBD request is
>> pending, the atsk that waits for the result (in this case *rsync*) is
>> refusing to freeze. This happens even when setting a 5 minute timeout
>> for freezing (which is more than enough time for the NBD request to
>> complete), so I suspect that the NBD server task (in this case nbdkit)
>> has already been frozen and is thus unable to make progress.
>> However, I do not understand why the same is not happening for FUSE
>> (with FUSE requests being stuck because the FUSE daemon is already
>> frozen). Was I just very lucky in my tests? Or are tasks waiting for
>> FUSE request in a different kind of state? Or is NBD a red-herring here,
>> and the real trouble is with ZFS?
>> It would be great if someone  could shed some light on what's going on.
>
> I guess it is a generic issue also affecting fuse, see this patch
>
> https://lore.kernel.org/lkml/20220511013057.245827-1-dlunev@chromium.org/
>
> A bit down the thread you can find a reference to this ancient patch
>
> https://linux-kernel.vger.kernel.narkive.com/UeBWfN1V/patch-fuse-make-fuse-daemon-frozen-along-with-kernel-threads

Interesting, thank you for the link! So it seems that I just got lucky
with FUSE.

Does anyone know in which order the kernel freezes processes by default?
Could I perhaps work around the problem by calling the FUSE/NBD daemon
something like "zzzzz_mydaemon"?


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

  reply	other threads:[~2022-09-07 15:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30  6:31 Why do NBD requests prevent hibernation, and FUSE requests do not? Nikolaus Rath
2022-08-30 23:02 ` Bernd Schubert
2022-09-07 15:50   ` Nikolaus Rath [this message]
2022-09-02 12:49 ` Wouter Verhelst
2022-09-07 10:18   ` Nikolaus Rath
2022-09-16  8:05   ` Nikolaus Rath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zgfbqj46.fsf@vostro.rath.org \
    --to=nikolaus@rath.org \
    --cc=bernd.schubert@fastmail.fm \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=nbd@other.debian.org \
    --cc=w@uter.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.