>>>>> "r" == Rince <rincebr...@gmail.com> writes:
r> *ZFS* shouldn't panic under those conditions. The disk layer,
r> perhaps, but not ZFS.
well, yes, but panicing brings down the whole box anyway so there is
no practical difference, just a difference in blame.
I would rather say, the fact that redundant ZFS ought to be the
best-practice proper way to configure ~all filesystems in the future,
means that disk drivers in the future ought to expect to have ZFS
above them, so panicing when enough drives are still available to keep
the pool up isn't okay, and also it's not okay to let problems with
one drive interrupt access to other drives, and finally we've still no
reasonably-practiceable consensus on how to deal with timeout
problems, like vanishing iSCSI targets, and ATA targets that remain
present but take 1000x longer to respond to each command, as ATA disks
often do when they're failing and as is, I suspect, well-handled by
all the serious hardware RAID storage vendors.
With some chips writing a good driver has proven (on Linux) to be
impossible, or beyond the skill of the person who adopted the chip, or
beyond the effort warranted by the chip's interestingness. well,
fine, but these things are certainly important enough to document, and
on Linux they ARE documented:
http://ata.wiki.kernel.org/index.php/SATA_hardware_features
It's kind of best-effort, but still it's a lot better than ``all those
problems on X4500 were fixed AGES ago, just upgrade'' / ``still having
problems'' / ``ok they are all fixed now'' / ``no they're not, still
can't hotplug, still no NCQ'' / ``well they are much more stable
now.'' / ``can I hotplug? is NCQ working?'' / .......
Note the LSI 1068 IT-mode cards driven by the proprietary 'mpt' driver
are supported, by a GPL driver, on Linux, and smartctl works on these
cards. but they don't appear on the wiki above, so Linux's list of
chip features isn't complete, but it's a start.
r> As far as it should be concerned, it's equivalent to ejecting
r> a disk via cfgadm without telling ZFS first, which *IS* a
r> supported operation.
an interesting point!
Either way, though, we're responsible for the whole system. ``Our new
handsets have microkernels, which is excellent for reliability! In the
future, when there's a bug, it won't crash the whole celfone. It'll
just crash the, ahh, the Phone Application.'' riiiight, sure, but SO
WHAT?!
pgpFIN4mApS1p.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
