>>>>> "ml" == Mark Little <marklit...@koallo.com> writes:
ml> Just to clarify - do you mean TLER should be off or on?
It should be set to ``do not have asvc_t 11 seconds and <1 io/s''.
...which is not one of the settings of the TLER knob.
This isn't a problem with the TLER *setting*. TLER does not even
apply unless the drive has a latent sector error.
TLER does not even apply unless the drive has a latent sector error.
TLER does not even apply unless the drive has a latent sector error.
GOT IT? so if the drive is not defective, but is erratically having
huge latency when not busy, this isn't a TLER problem. It's a
drive-is-unpredictable-piece-of-junk problem. Will the problem go
away if you change the TLER setting to the opposite of whatever it is?
Who knows?! It shouldn't based on the claimed purpose of TLER, but in
reality, maybe, maybe not, because the drive shouldn't (``shouldn't'',
haha) act like that to begin with. It will be more likely to go away
if you replace the drive with a different model, though.
ml> Storage forum on hardforum.com, the experts there seem to
ml> recommend NOT having TLER enabled when using ZFS as ZFS can be
ml> configured for its timeouts, etc,
I don't believe there are any configurable timeouts in ZFS. The ZFS
developers take the position that timeouts are not our problem and
push all that work down the stack to the controller driver and the
disk driver, which cooperate (this is two drivers, now. plus a third
``SCSI mid-layer'' perhaps, for some controllers but not others.) to
implement a variety of inconsistent, silly, undocumented cargo-cult
flailing timeout regimes that we all have to put up with. However
they are always quite long. The ATA max timeout is 30sec, and AIUI
they are all much longer than that.
My new favorite thing, though, is the reference counting. OS: ``This
disk/iSCSIdisk is `busy' so you can't detach it''. me: ``bullshit.
YOINK, detached, now deal with it.'' IMO this area is in need of some
serious bar-raising.
ml> and the main reason to use TLER is when using those drives
ml> with hardware RAID cards which will kick a drive out of the
ml> array if it takes longer than 10 seconds.
yup.
which is something the drive will not do unless it encounters an
ERROR. that is the E in TLER. In other words, the feature as
described prevents you from noticing and invoking warranty replacement
on your about-to-fail drive. For this you pay double. Have I got
that right?
In any case the obvious proper place to fix this is in the
RAID-on-a-card firmware, not the disk firmware, if it does even need
fixing which is unclear to me. unless the disk manufacturers are
going to offer a feature ``do not spend more than 1 second out of
every 2 seconds `trying harder' to read marginal data, just return
errors'' which woudl actually have real value, the only reason TLER is
proper is that it can convince all you gamers to pay twice as much for
a drive because they've flipped a single bit in the firmware and then
shovelled a big pile of bullshit into your heads.
ml> Can anyone else here comment if they have had experience with
ml> the WD drives and ZFS and if they have TLER enabled or
ml> disabled?
I do not have any problems with drives dropping out of ZFS using the
normal TLER setting.
I do have problems with slowly-failing drives fucking up the whole
system. ZFS doesn't deal with them gracefully, and I have to find the
bad drive and remove it by hand. All this stuff about cold spares
automatically replacing and USARS never notice, is largely a fantasy.
Neither observation leads me to want TLER.
however observations like this ``why did my disks suddenly slow
down?'' lead me to avoid WD drives period, for ZFS or not ZFS or
anything at all. Whipping up all this marketing sillyness around TLER
also leads me to avoid them because I know they will shovel bullshit
and FUD to justify jacked prices.
pgpMng48rq0w8.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
