Martin K. Petersen wrote:
"Bill" == Bill Davidsen <davidsen@xxxxxxx> writes:
FWIW, XFS and btrfs both use the page writeback bit correctly and
never change a page while it is undergoing I/O.
Bill> That's necessary but not sufficient. To be done correctly it must
Bill> be protected by md as well. This is because arrays are used
Bill> without a filesystem by some applications, such as swap and
Bill> database, to name the most common cases.
I agree that making MD RAID1 do a copy would be a quick fix. But I
don't see any reason to encourage what is essentially sloppy behavior at
the top of the stack. And then what if you stack MD/DM devices? Do
each layer do a copy? I think that gets murky pretty quickly.
Which is why I suggested that the ideal implementation is COW, which in
most cases would need no copy unless the pages were attempted to be
modified. That requires some assumptions about how the buffers are
aligned vs. memory pages, and are hardware dependent to some extent.
It's not easy, but I never said it was. The question is if it is
*required* in some places, as determined by (a) good practice if the
overhead is low, or (b) user option for "safe even if slow."
I'd much rather fix the cases where the top layers are broken. And as I
said there are several people working on this spurred by my work on the
data integrity extensions.
FWIW, databases on raw disk have gone out of fashion. But it is true
that applications that do direct I/O need to avoid updating buffers in
flight.
May have gone out of fashion in new applications (I'm not sure I agree,
but as a talking point), but there are tons of old apps which are not
going to be updated any time soon, and any number of libraries which
mmap stuff and effect multiple applications.
--
Bill Davidsen <davidsen@xxxxxxx>
"We can't solve today's problems by using the same thinking we
used in creating them." - Einstein
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
