Comment 4 for bug 883748

Hi,

On Sun, Oct 30, 2011 at 11:31 PM, Steve <email address hidden> wrote:
> First,  problems can occur because there may be open files on the device
> when the system is suspended. Due to delays in enumeration, the external
> device will not immediately be back when the system is resumed. Thus,

It will be so if reset_resume is set for the usb mass storage device
during resume.

> the effect is that of essentially unplugging the device without
> unmounting it first. Any processes that have files open on the device
> will now have an invalid file handle and will not be able to write to
> those files. While this alone may not immediately result in corruption
> at the filesystem level, it may certainly result in corruption or
> inconsistency at the data level (eg. if a process is writing related
> data to two files, one on the internal drive and one on an external
> drive, and the external drive suddenly goes away due to suspend).

Sounds like writing to filesystem on external device is not finished
before suspending. After resuming, the writing is ongoing but
failed because of reset on external usb device.

PM guys are discussing on linux-pm about suspend block mechanism,
looks like it can prevent the problem from being triggered.

>
> Second, I am seeing logs in dmesg about how the filesystem was not
> unmounted cleanly (obviously) and also seeing journal replay. Removing
> the device after doing 'sync' should not really result in a journal
> replay unless disk inconsistency is happening, which is what I am seeing
> here.

For the partial writing to filesystem on external device, looks like it should
not be a disaster for filesystem and the fs should deal with this case, such as
just mark this writing as failure and do not corrupt the whole filesystem.

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.

thanks,
--
Ming Lei