Re: what is our answer to ZFS?

["jdow" <jdow@earthlink.net>]

From: "Matthias Andree" <matthias.andree@gmx.de>

> On Mon, 21 Nov 2005, Kasper Sandberg wrote:
>
> > On Mon, 2005-11-21 at 12:46 +0100, Matthias Andree wrote:
> > > On Mon, 21 Nov 2005, Jörn Engel wrote:
> > >
> > > > o Checksums for data blocks
> > > >   Done by jffs2, not done my any hard disk filesystems I'm aware of.
> > >
> > > Then allow me to point you to the Amiga file systems. The variants
> > > commonly dubbed "Old File System" use only 448 (IIRC) out of 512 bytes
>
> Make that 488. Amiga's traditional file system loses 6 longs (at 32 bit
> each) according to Ralph Babel's "The Amiga Guru Book".

FYI it was not used very often on hard disk file systems. The affect on
performance was "remarkable". Each disk block contained a simple ulong
checksum, a pointer to the next block in the file, and a pointer to the
previous block in the file. The entire file system was built of doubly
linked lists. It was possible to effect remarkable levels of "unerase"
and recover from disk corruption better than most other filesystems I
have seen. But it bad watching glass flow seem fast when you tried to
use it. So as soon as the Amiga Fast File System, FFS, was developed
OFS became a floppy only tool. That lasted until FFS was enabled for
floppies, months later. Then OFS became a legacy compatability feature
that was seldom if ever used by real people. I am not sure how I would
apply a checksum to each block of a file and still maintain reasonable
access speeds. It would be entertaining to see what the ZFS file system
does in this regard so that it doesn't slow down to essentially single
block per transaction disk reads or huge RAM buffer areas such as had
to be used with OFS.

> > > in a data block for payload and put their block chaining information,
> > > checksum and other "interesting" things into the blocks. This helps
> > > recoverability a lot but kills performance, so many people (used to) use
> > > the "Fast File System" that uses the full 512 bytes for data blocks.
> > >
> > > Whether the Amiga FFS, even with multi-user and directory index updates,
> > > has a lot of importance today, is a different question that you didn't
> > > pose :-)

Amiga FFS has some application today, generally for archival data
recovery. I am quite happy that potential is available. The Amiga FFS
and OFS had some features mildly incompatable with 'ix type filesystems
and these features were used frequently. So it is easier to perpetuate
the old Amiga FFS images than to copy them over in many cases.

> > that isnt true, just because it isnt following the kernel coding style
> > and therefore has to be changed, does not make it any bit more unstable.
>
> If the precondition is "adhere to CodingStyle or you don't get it in",
> and the CodingStyle has been established for years, I have zero sympathy
> with the maintainer if he's told "no, you didn't follow that well-known
> style".

Personally I am not a fan of the Linux coding style. However, if I am
going to commit a patch or a large block of Linux only code then its
style will match my understanding of the Linux coding style. This is
merely a show of professionalism on the part of the person creating the
code or patch. A brand new religious war over the issue is the mark of
a stupid boor at this time. It is best to go with the flow. The worst
code to maintain is code that contains eleven thousand eleven hundred
eleven individual idiosyncratic coding styles.

> Matthias Andree

{^_^}   Joanne Dow, who pretty much knows Amiga filesystems inside and
       out if I feel a need to refresh my working memory on the subject.


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