Hi! > > > The reason for freezing those tasks is to avoid writebacks at random > > > times during a system sleep transition, when the underlying device may > > > already be suspended, right? > > > > It is also there to avoid inconsistency between in-filesystem data and > > snapshot in hibernation image. > > A good point, although in this case I think it won't matter. Writing > out a dirty page twice (once right after taking the snapshot and then > again after resuming from hibernation) will leave the disk in a correct > state. No, I don't think so. Have you considered all the various journalling systems? Definitely not in presence of I/O errors. Commit block can only be written after previous blocks are successfully writen to the journal. So lets see: <snapshot> Write previous block, write commit block, write more blocks <hibernation powerdown, restart> Error writing previous block (block now contains garbage), leading to kernel panic <restart> journalling assumptions broken: commit block is there, but previous blocks are not intact. Data loss. ...and that was the first I could think about. Lets not do this. Barriers were invented for a reason. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
