On Wed, 4 Jun 2008 12:19:25 +0200 Jan Kara <jack@xxxxxxx> wrote: > On Tue 03-06-08 15:30:50, Andrew Morton wrote: > > On Mon, 02 Jun 2008 19:43:57 +0900 > > Hidehiro Kawai <hidehiro.kawai.ez@xxxxxxxxxxx> wrote: > > > > > > > > In ordered mode, we should abort journaling when an I/O error has > > > occurred on a file data buffer in the committing transaction. > > > > Why should we do that? > I see two reasons: > 1) If fs below us is returning IO errors, we don't really know how severe > it is so it's safest to stop accepting writes. Also user notices the > problem early this way. I agree that with the growing size of disks and > thus probability of seeing IO error, we should probably think of something > cleverer than this but aborting seems better than just doing nothing. > > 2) If the IO error is just transient (i.e., link to NAS is disconnected for > a while), we would silently break ordering mode guarantees (user could be > able to see old / uninitialized data). > Does any other filesystem driver turn the fs read-only on the first write-IO-error? It seems like a big policy change to me. For a lot of applications it's effectively a complete outage and people might get a bit upset if this happens on the first blip from their NAS. <waves vigorously at linux-ext4 people> -- 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
