On Tue, 10 Jun 2008 17:51:35 +0900 Hidehiro Kawai <hidehiro.kawai.ez@xxxxxxxxxxx> wrote: > Hello Andrew, > > akpm@xxxxxxxxxxxxxxxxxxxx wrote: > > > The patch titled > > jbd: strictly check for write errors on data buffers > > has been removed from the -mm tree. Its filename was > > jbd-strictly-check-for-write-errors-on-data-buffers.patch > > > > This patch was dropped because I don't think we want to go read-only on file data write errors > > > > The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ > > > > ------------------------------------------------------ > > Subject: jbd: strictly check for write errors on data buffers > > From: Hidehiro Kawai <hidehiro.kawai.ez@xxxxxxxxxxx> > > This patch series doesn't change the behavior on file data write > errors as I stated before, but we found that the current behavior has > been made accidentally. So yesterday I sent an additional patch(*) > which removes the invocation of journal_abort() and thus stop making > the fs read-only on file data write errors, but it seems to be late > for the -mm release preparation. > > Patch(*) can be found at: > http://marc.info/?l=linux-kernel&m=121300618614453&w=2 > > Anyway, as this patch series was dropped from -mm, I'm going to > send a revised version. > > I plan to separate these pathces into three patche set. > The first patch (set) corrects the current behavior in ordered > writes, it means it removes the invocation of journal_abort() on file > data write errors. It is the almost same as the patch(*). > The second patch set fixes error handlings for metadata writes and > checkpointing. It should be applied independently of the first > patch set, and it is the same as PATCH 3/5 to 5/5. > The third patch set makes "abort the journal on file data write errors" > tunable for mission critical users. Of course, this feature depends > on the first patch set. > That sounds like a good plan, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
