>>>>> "bmm" == Bogdan M Maryniuk <bogdan.maryn...@gmail.com> writes: >>>>> "tt" == Toby Thain <t...@telegraphics.com.au> writes:
bmm> That's why I think that speaking "My $foo crashes therefore it
bmm> is all crap" is bad idea: either help to fix it or just don't
bmm> use it,
First, people are allowed to speak and share information, and yes,
even complain, without helping to fix things. You do not get to
silence people who lack the talent, time, and interest to fix
problems. Everyone's allowed to talk here.
Second, I do use ZFS. But I keep a backup pool. And although my
primary pool is iSCSI-based, the backup pools are direct-attached.
Thanks to the open discussion on the list, I know that using iSCSI
puts me at higher risk of pool loss. I know I need to budget for the
backup pool equipment if I want to switch from $oldfilesystem to ZFS
and not take a step down in reliability. I know that, while there is
no time-consuming fsck to draw out downtime, pretty much every
corruption event results in ``restore the pool from backup'' which
takes a while, so I need to expect that by, for example, being
prepared to run critical things directly off the backup pools.
Finally, I know that ZFS pool corruption almost always results in loss
of the whole pool, while other filesystem corruption tends to do
crazier things which cappen to be less catastrophic to my particular
dataset: some files but not all are lost after fsck, some files remain
but lose their names, or more usefully retain their names but lose the
name of one of their parent directories, the insides of some files are
silently corrupted.
There's actionable information in here. Technical discussion is worth
more than sucks/rules armwrestling.
bmm> The same way, if you have a mirror of USB hard drives, then
bmm> swap cables and reboot — your mirror gone. But that's not
bmm> because of ZFS, if you will look more closely...
actually I think you are the one not looking closely enough. You say
no one is losing pools, and then 10min later reply to a post about
running zdb on a lost pool. You shouldn't need me to tell you
something's wrong.
When you limit your thesis to ``ZFS rules'' and then actively mislead
people, we all lose.
tt> /. is no person...
right, so I use a word like ad hominem, and you stray from the main
point to say ``Erm ayctually your use of rhetorical terminology is
incorrect.'' maybe, maybe not, whatever, but
again [x2], the posts in the slashdot thread complaining about
corruption were just pointers to original posts on this list, so
attacking the forum where you saw the pointer instead of the content
of its destination really is clearly _ad hominem_.
*brrk* *brr* ``no! no it's not ad hominem! it's a different word!
ah, ha ah thought' you'd slip one past me there eh?'' QUIT BEING SO
DAMNED ADD. We can get nowhere.
As for the posts being rubbish, you and I both know it's plausible
speculation that Apple delayed unleashing ZFS on their consumers
because of the lost pool problems. ZFS doesn't suck, I do use it, I
hope and predict it will get better---so just back off and calm down
with the rotten fruit. But neither who's saying it nor your not
wanting to hear it makes it less plausible.
pgpqQ7LsTK2De.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
