Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

[Ric Wheeler <ric@emc.com>]

Alan Cox wrote:
> Ar Maw, 2006-08-01 am 16:52 +0200, ysgrifennodd Adrian Ulrich:
>
> > WriteCache, Mirroring between 2 Datacenters, snapshotting.. etc..
> > you don't need your filesystem beeing super-robust against bad sectors
> > and such stuff because:
>
>
> You do it turns out. Its becoming an issue more and more that the sheer
> amount of storage means that the undetected error rate from disks,
> hosts, memory, cables and everything else is rising.


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...

ric


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/