I somewhat doubt it's a driver thing, since it happens only with WD drives, and
it happens with both the mpt and mpt_sas drivers.
roy
- Original Message -
> Oh I see, I thought you were misusing the term sector and so I went
> along
> with your terminology.
>
> I realize this is a hardw
This is not a TLER issue. If it were, I'd be seeing media errors on the drives
in question over time, which isn't the case. Also, WD drives, TLER or not, seem
to work quite well with direct attach, just not on this LSI/supermicro SAS
expander.
Also, flashing drives with TLER firmware stopped wo
Roy - Though it doesn't offer much by way of solution to the Western Digital
Dilemma, I can reinforce your assertions re Hitachi: We've got a very
nicely-running ZFS array comprised of 2TB Hitachi Desktars; built partly with
your help, as you recall.
Great performance - and it's been rock soli
TLER was removed from the consumer drives in one of the rounds of firmware
upgrades. That tunable is now only available in the enterprise versions of
the disk -- at least that is my understanding.
If you have fix it in the OS, it is going to be more expensive. See my last
email on this.
j.
--
Would tuning the kernel to deal with the super slow time-outs of consumer
grade drives help? It is not going to make your consumer drive an enterprise
product, or keep your performance high, but it might keep FMD from failing
out your entire pool and/or corrupting the pool.
These are guestimat
Oh I see, I thought you were misusing the term sector and so I went along
with your terminology.
I realize this is a hardware/driver thing, but by increasing the blocksize,
it may change the number of interrupts per operation (or otherwise change
the temporal characteristics with which the driver
the WD drives have a what WD call TLER, that is a setting that defines
how long the drive trys to read a bad sector before giving up at
returning an error. The raid edition does this almost instantly and the
RAID hardware / ZFS can then decide what to do. The non RAID edition
retries for a long
file systems don't have sectors, they have blocks. and zfs normally uses
512b-128k blocks, which is fine. this issue won't be fixed by reducing the
recordsize in zfs, it's a hardware/driver thing
- Original Message -
> I think Rich was suggesting using 4k sectors on the file system, not
I think Rich was suggesting using 4k sectors on the file system, not asking
what the drives sector size was.
On Mon, Aug 29, 2011 at 2:15 PM, Roy Sigurd Karlsbakk wrote:
> All drives have 512b sector sizes, WD FASS (blacks) and WD EADS (greens)
> both use plain old 512 sectors.
>
> - Orig
And, yes, they're connected to an LSI SAS expander from Super Micro. Works well
with Seagate and Hitachi, but not with WD
- Original Message -
> The drives are attached to a backplane?
>
> Try using 4k sector sizes and see if that improves it - I've seen and
> been part of a number o
All drives have 512b sector sizes, WD FASS (blacks) and WD EADS (greens) both
use plain old 512 sectors.
- Original Message -
> The drives are attached to a backplane?
>
> Try using 4k sector sizes and see if that improves it - I've seen and
> been part of a number of discussions whi
The drives are attached to a backplane?
Try using 4k sector sizes and see if that improves it - I've seen and
been part of a number of discussions which involved this - and you, I
think, actually.
- Rich
On Mon, Aug 29, 2011 at 5:07 PM, Roy Sigurd Karlsbakk
wrote:
> Hi all
>
> It seems recent
Hi all
It seems recent WD drives that aren't "Raid edition" can cause rather a lot of
problems on RAID systems. We have a few machines with LSI controllers
(6801/6081/9201) and we're seeing massive errors occuring. The usual pattern is
a drive failing or even a resilver/scrub starting and then,
On Sun, Aug 28, 2011 at 23:46, Alex Viskovatoff wrote:
> You are apparently unaware of oi-sfe:
> http://wiki.openindiana.org/oi/SFE+IPS+Repository
>
> That has Transmission 2.2. It isn't up to 3.* yet because 3.1 had
> serious problems, and it's not clear to everybody that those have been
> fixed.
14 matches
Mail list logo