Bryan Henderson wrote:
A barrier doesn't say any particular data must sync-to-platter.
I was told by a blkdev expert that there are barrier sequences
that will do this... which probably means I asked the wrong questions.
My further understanding is that some layers (and devices)
have bugs and don't sync-to-platter.
Those aren't bugs. They're conscious design choices, so the worst you can
say about them is they are design defects. The designer decided that the
user would be more upset by constant slowness than by exposure to data
loss in certain situations. Yes, even though the user's program or OS
explicitly requested sync-to-platter. But I agree the behavior should be
documented -- probably in every listing of the device's specifications.
I know it is often a design choice for some system vendors to
say they are posix compliant while not meeting the data
integrity requirements just so they can win benchmarks. They
don't document it, they hope they never get caught. Or do you
think the specs don't require data to reach non-volatile storage?
I'm not worried about devices since I can tell customers to buy
ones that work. I'm worried if the kernel won't save user data.
Trying to convince customers to move off proprietary systems and
onto linux is a tough sell if we don't really protect their data.
So I think I'll put finding a solution to fsync somewhere near the
top of my own todo list.
The large commercial users we (HP) want to pay my expenses would
be a little unforgiving about fsync not working... and they keep
packs of underfed lawyers in kennels :)
jim
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
