Comment 6 for bug 883748

On Tue, Nov 1, 2011 at 2:44 AM, Steve <email address hidden> wrote:
>> Could you make sure that the filesystem(REISERFS) on the external device
>> has been destroyed? If only the single file is affected, it should not be a big
>> deal.
>
> I'm sorry, but this is unacceptable. It is not correct for even a single
> file to be affected by this problem. What if it happens to be a very
> important file? When it comes to filesystem integrity, it's either fully
> correct or it isn't - there is no "partial credit" here.

Yes, it should be a kind of critical things.

In fact, I mean the problem has been in linux kernel for long time if it is so.

Suspend blocker mechanism may prevent the problem from being
triggered if it is applied properly, but it is still under discussion
on upstream.
At least now, system sleep can happen at any time. If it does happen during
writing file, file or fs corruption may be caused as the issue.

BTW, I am still not sure if the partial writing before suspend caused
the problem.

>
> The workaround can be done entirely from userspace, without having to
> wait for linux-pm guys to sort their stuff out. Back when I ran a gentoo
> box, I had a suspend script with a simple 5 lines of shell code which
> tried to unmount external devices, and did not initiate suspend unless
> this operation completed. Sure, the problem would still occur if you

You may not umount successfully if accesses to the filesystem is
pending or ongoing.

> directly echo mem > /sys/power/state, but at least clicking 'Suspend'
> from the UI would try to do the right thing first, and fail to suspend
> if unmounting was unsuccessful.
>
> Maybe I will just go back to that script on this system.

thanks,
--
Ming Lei