On Mon 26-02-18 10:25:55, Rafael J. Wysocki wrote:
> On Sun, Feb 25, 2018 at 6:22 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote:
> > Ah, yes, I see your point now. So for filesystems we really don't
> > care if its suspend or hibernation, we just need to freeze in the right
> > order. So long as we get that order right we should be OK.
>
> Generally, yes.
>
> System suspend/resume (S2R, S2I), however, doesn't really require the
> flushing part, so in principle the full-blown fs freezing is not
> necessary in that case, strictly speaking. The ordering of writes
> still has to be preserved in this case (that is, writes to persistent
> storage in the presence of a suspend-resume cycle must occur in the
> same order as without the suspend-resume), but it doesn't matter too
> much when the writes actually happen.
I agree that in principle we don't have to flush all dirty data from page
cache before system suspend (I believe this is what you are speaking about
here, isn't it?). However from implementation POV it is much simpler that
way as otherwise processes get blocked in the kernel in unexpected places
waiting for locks held by blocked flusher threads etc.
> They may be carried out before
> the suspend or after the resume or somewhere during one of them: all
> should be fine so long as the ordering of writes doesn't change as a
> result of the suspend-resume (and suspend-resume failures are like
> surprise resets from the fs perspective in that case, so journaling
> should be sufficient to recover from them).
Err, I don't follow how suspend failure looks like surprise reset to the
fs. If suspend fails, we just thaw the filesystem and off we go, no IO
lost. If you speak about a situation where you suspend but then boot
without resuming - yes, that looks like a surprise reset and it behaves
that way already today.
> Of course, the full-blown freezing will work for system suspend too,
> but it may be high-latency which is not desirable in some scenarios
> utilizing system suspend/resume ("dark resume" or "lucid sleep"
> scenarios, for example). That will be a concern in the long run (it
> kind of is a concern already today), so I would consider
> special-casing it from the outset.
Understood but that would require considerable amount of work on the fs
side and the problem is hard enough as is :) And switching the freeze
implementation to avoid sync(2) if asked to is quite independent from
implementing system suspend to use fs freezing.
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
