[PATCH] UBUNTU: [Config] ext3 defaults to ordered mode

Ben Hutchings ben at decadent.org.uk
Fri Jan 22 02:13:11 UTC 2010


On Thu, 2010-01-21 at 07:00 -0700, Tim Gardner wrote:
> I am not in agreement. ORDERED was the implicit default _before_ Karmic
> because there was no other option. However, Karmic has _not_ had ORDERED
> set since the first 2.6.30 based release. Changing ORDERED at this point
>  changes the fundamental behavior of the file system. I think we need to
> solicit the considered opinion of our platform brethren. I have no idea
> how this might affect select() or poll() or other file system
> notification mechanisms.

It has no effect.  Filesystems do not support non-blocking I/O (at least
not in the sense that sockets and pipes do).

> SRU policy states that patches must fix a real problem. IMHO this does
> not fix the root issue, which is the crash, _not_ the file system
> corruption.

In general a bug which causes a crash might also corrupt the writeback
cache some time before bringing the system down.  However there are many
classes of bugs that will crash the system without causing such memory
corruption beforehand.  Furthermore, unclean shutdown may be the result
of power loss rather than a crash.  In that case, surely the filesystem
behaviour *is* the root issue, from a kernel maintainer's perspective?

> No file system code will be able to withstand crashes at the
> right critical point.
[...]

So long as a filesystem uses appropriate I/O barriers, and the
underlying system implements them, it is possible to reduce the
possibility of this sort of data corruption nearly to zero.  And that is
what ext3 did by default until recently.

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable from a rigged demo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20100122/13ab03ab/attachment.sig>


More information about the kernel-team mailing list