Michael Rothwell writes:
> 4) A high reliability internal file system.
>
> Ext2 + bdflush + kupdated? Not likely. To quote the Be Filesystems
> book, Ext2 throws safety to the wind to achieve speed. This also ties
> into Linux' convoluted VM system, and is shot in the foot by NFS. We
> would need minimally a journaled filesystem and a clean VM design,
> probably with a unified cache (no separate buffer, directory entry and
> page caches). The Tux2 Phase Trees look to be a good step in the
> direction as well, in terms of FS reliability.
Ext3 is doing pretty well...
> The filesystem would have
> to do checksums on every block. Some type of mirroring/clustering would
> be good. And the ability to grow filesystems online, and replace disks
> online, would be key. If your disks are getting old, you may want to
> pre-emptively replace them with faster, newer, larger ones with more
> MTBF left.
You can always do this in the hardware - no reason to do it in software.
If you are using RAID 5, and you wanted to take the performance hit you
could always calculate the checksums for each stripe on read to detect
errors. You may even be able to add a second parity disk to do ECC on
the disk data.
As for online resizing, you can do this with ext2 for a long time with
my ext2online patches/tools. LVM lets you migrate between disks online.
You need hardware support (available) to do hot-swap disks - SCSI works,
but I don't think the IDE code is ready for hot-swap yet.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Nov 15 2000 - 21:00:26 EST