The trouble with stable pages [LWN.net]

The trouble with stable pages

Posted Mar 15, 2012 10:32 UTC (Thu) by intgr (subscriber, #39733)
Parent article: The trouble with stable pages

> occasionally, as described by Ted Ts'o, processes performing writes can
> find themselves blocked for lengthy periods (multiple seconds) of time

Really, why wasn't that obvious at the time the patch written? While Wu Fengguang is working hard to improve interactivity during heavy write I/O, other developers are hell bent on adding new nasty behavior. Here's another instance of pretty much the same problem: https://lwn.net/Articles/467328/

The whole point of writeback is that user space shouldn't have to wait behind slow disks. But suddenly, now, it's OK to make user space wait for the whole I/O queue to clear in common cases, for the sake of obscure new features.

to post comments

The trouble with stable pages

Posted Mar 15, 2012 13:06 UTC (Thu) by Spudd86 (guest, #51683) [Link] (1 responses)

The feature isn't obscure... it's a correctness feature in btrfs, and hardware support elsewhere.

Basically btrfs needs to know that the checksum is right because it will check the checksum when the page is read from disk next, so if it can't do that it WILL report spurious errors and potentially loose data depending on how your app or you react.

The trouble with stable pages

Posted Mar 15, 2012 14:00 UTC (Thu) by intgr (subscriber, #39733) [Link]

> The feature isn't obscure...

Well btrfs users had to deal with this from day one there's no regression there.

But most users are using ext3/4, and most of them certainly aren't using compression or hardware block checksums -- hence obscure.