Page MenuHomeFreeBSD

POC code to sync on suspend
AbandonedPublic

Authored by imp on Nov 1 2020, 8:17 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 20 2023, 5:04 AM
Unknown Object (File)
Nov 10 2023, 8:41 AM
Unknown Object (File)
Nov 7 2023, 7:03 AM
Unknown Object (File)
Oct 6 2023, 6:00 AM
Unknown Object (File)
Sep 18 2023, 6:01 AM
Subscribers
None

Details

Reviewers
kib
mckusick
markj
Summary

Abstract out the sync on shutdown code and add call to it
from the suspend path at an opportune spot.

We have a reset on resume bug (at least for my laptop)
and I'm growing weary of the fsck spewing several screens when
there's lots of dirty buffers.

This seems to mostly solve the problem: the filesystem still gets
fsck'd because it's marked as dirty, but no further damage is apparent.

This is the first cut at doing this, and is being circulated for review
and comments.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 34546
Build 31641: arc lint + arc unit

Event Timeline

imp requested review of this revision.Nov 1 2020, 8:17 PM
imp created this revision.

I am not sure that this sync is very useful. I am not even sure that we do need it for normal shutdown, but for shutdown the rationale could be that later unmount might fail, e.g. in situation where we have unkillable processes, and then at least syncing user data is nice.

Normal shutdown does unmount after sync, and it is unmount that really guarantees that all data and metadata is on the permanent storage.

Also, this sync only works when filesystems use buffer cache. In other words, on ZFS-only machine it does nothing, might be it is fine since ZFS is not supposed to corrupt on-disk data.

Might be, the better way to do what you want is to suspend all rw filesystems.

sys/kern/vfs_bio.c
1366

Is this a right thing to do when called from suspend ?

In D27042#603494, @kib wrote:

I am not sure that this sync is very useful. I am not even sure that we do need it for normal shutdown, but for shutdown the rationale could be that later unmount might fail, e.g. in situation where we have unkillable processes, and then at least syncing user data is nice.

There's about 100 dirty buffers when I call it for suspend. It's useful. However, flushing that might be accomplished better by other means?

Normal shutdown does unmount after sync, and it is unmount that really guarantees that all data and metadata is on the permanent storage.

True. I thought this was useful when those weren't able to succeed, but maybe it used to be useful and isn't anymore.

Also, this sync only works when filesystems use buffer cache. In other words, on ZFS-only machine it does nothing, might be it is fine since ZFS is not supposed to corrupt on-disk data.

Might be, the better way to do what you want is to suspend all rw filesystems.

Great! Is there a pointer for how best to do this somewhere?