I agree with Alan despite being an enthusiastic supporter of neat array based technologies.

Most people use absolutely giant disks in laptops and desktop systems (300GB & 500GB are common, 750GB on the way). File systems need to be as robust as possible for users of these systems as people are commonly storing personal "critical" data like photos mostly on these unprotected drives.

Even for the high end users, array based mirroring and so on can only do so much to protect you.

Mirroring a corrupt file system to a remote data center will mirror your corruption.

Rolling back to a snapshot typically only happens when you notice a corruption which can go undetected for quite a while, so even that will benefit from having "reliability" baked into the file system (i.e., it should grumble about corruption to let you know that you need to roll back or fsck or whatever).

An even larger issue is that our tools, like fsck, which are used to uncover these silent corruptions need to scale up to the point that they can uncover issues in minutes instead of days. A lot of the focus at the file system workshop was around how to dramatically reduce the repair time of file systems.

In a way, having super reliable storage hardware is only as good as the file system layer on top of it - reliability needs to be baked into the entire IO system stack...