>>>>> "bm" == Brandon Mercer <yourcomputer...@gmail.com> writes:
>> I'm now starting to feel that I understand this issue,
>> and I didn't for quite a while. And that I understand the
>> risks better, and have a clearer idea of what the possible
>> fixes are. And I didn't before.
haha, yes, I think I can explain it to people when advocating ZFS, but
the story goes something like ``ZFS is serious business and pretty
useful, but it has some pretty hilarious problems that you wouldn't
expect from some of the blog hype you read. Let me give you a couple
examples of things that still aren't fixed and how the discussion
went...''
bm> Excellent, can this thread die now? :P
If no one is going to fix the problem, I guess so. I'm not intending
to submit a patch myself---I'll just use fletcher4 or sha256 for the
bulk pool, and cross my fingers for the ZIL. I'm not even sure there
is any point in submitting a patch because it sounds like the problem
is political, not code. Fixing the math mistake would be trivial for
the person who originally wrote broken-fletcher2, but if you break
pool compatibility, you widen the discussion about the original broken
checksum to include all the ZFS-loving the hype-blogs.
I'm just surprised the bug is closed without fixing the problem, and
that any ZFS user who didn't participate in this thread will almost
certainly still end up creating pools with broken checksums. That
doesn't seem right at all, especially when ZFS has so many simple
convenient paths for eventually fixing the problem.
Why not simply change the default for new filesystems to fletcher4?
This is backward-compatible. Because of the way opensolaris is
livecd-install-then-upgrade, new users will continue getting broken
checksums for several months even with this fix until the next livecd
comes out, but at least it's an eventual resolution.
As for the ZIL, why not change it to broken-fletcher4 the next time
the ZFS 'update' version is incremented? The ZIL is less urgent to
fix on a scale of months because users don't have to migrate all their
data to get the new checksum, so sites won't be stuck with broken ZIL
checksums after upgrading their software like they are for the bulk
data in the pool with livecd-then-upgrade. If fletcher4 is some
``performance issue'' (is it?), then implement nfletcher2 (correct
implementation of Fletcher's checksum) and include it in the new ZFS
version as the default.
The only argument I can think of for doing nothing is, it's like
mercury in vaccines or broken autoclaves---if you respond, it's
admitting there was a problem in the first place, while until you
respond you can balance the effort you spend fuzzing the issue against
your liability. However in this case I don't think anyone needs a 60
minutes exposee. It's impossible to argue the problem's imaginary,
especially after so much ZFS advocacy was based on drumming up FUD
about how naked you supposedly are without these checksums.
pgpqbGxMCOQB4.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
