By the way,
there are more than fifty bugs logged for marevell88sx, many of them about
problems with DMA handling and/or driver behaviour under stress.
Can it be that I'm stumbling upon something along these lines?
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6826483
Maurilio.
--
Richard,
it is the same controller used inside Sun's thumpers; It could be a problem in
my unit (which is a couple of years old now), though.
Is there something I can do to find out if I owe you that steak? :)
Thanks.
Maurilio.
--
This message posted from opensolaris.org
_
On Oct 4, 2009, at 11:52 PM, Maurilio Longo wrote:
Richard,
thanks for the explanation.
So can we say that the problem is in the disks loosing a command now
and then under stress?
It may be the disks or the HBA. I'll bet a steak dinner it is the HBA.
-- richard
_
Richard,
thanks for the explanation.
So can we say that the problem is in the disks loosing a command now and then
under stress?
Best regards.
Maurilio.
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolari
For the archives...
On Oct 2, 2009, at 12:41 AM, Maurilio Longo wrote:
Hi,
I have a pc with a MARVELL AOC-SAT2-MV8 controller and a pool made
up of a six disks in a raid-z pool with a hot spare.
-bash-3.2$ /sbin/zpool status
pool: nas
stato: ONLINE
scrub: scrub in progress for 9h4m, 81,5
Errata,
they're ST31000333AS and not 340AS
Maurilio.
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Carson,
they're seagate ST31000340AS with a firmware release CC1H, which from a rapid
googling should have no firmware errors.
Anyway, setting NCQ depth to 1
# echo zfs_vdev_max_pending/W0t1 | mdb -kw
did not solve the problem :(
Maurilio.
--
This message posted from opensolaris.org
__
Milek,
this is it
# iostat -En
c1t0d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Vendor: ATA Product: ST3808110AS Revision: DSerial No:
Size: 80,03GB <80026361856 bytes>
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 91 Predictive F
Maurilio Longo wrote:
Carson,
the strange thing is that this is happening on several disks (can it be that
are all failing?)
What is the controller bug you're talking about? I'm running snv_114 on this
pc, so it is fairly recent.
Best regards.
Maurilio.
See 'iostat -En' output.
__
Maurilio Longo wrote:
I did try to use smartmontools, but it cannot report SMART logs nor start
SMART tests, so I don't know how to look at their internal state.
Really? That's odd...
You could also have a firmware bug on your disks. You might try lowering
the number of tagged commands per d
> Possible, but less likely. I'd suggest running some
> disk I/O tests, looking at
> the drive error counters before/after.
>
These disks have a few months of life and are scrubbed weekly, no errors so far.
I did try to use smartmontools, but it cannot report SMART logs nor start SMART
tests,
Maurilio Longo wrote:
the strange thing is that this is happening on several disks (can it be that
are all failing?)
Possible, but less likely. I'd suggest running some disk I/O tests, looking at
the drive error counters before/after.
What is the controller bug you're talking about? I'm run
Carson,
the strange thing is that this is happening on several disks (can it be that
are all failing?)
What is the controller bug you're talking about? I'm running snv_114 on this
pc, so it is fairly recent.
Best regards.
Maurilio.
--
This message posted from opensolaris.org
Maurilio Longo wrote:
Hi,
I have a pc with a MARVELL AOC-SAT2-MV8 controller and a pool made up of a
six disks in a raid-z pool with a hot spare.
...
Now, the problem is that issuing an
iostat -Cmnx 10
or any other time intervall, I've seen, sometimes, a complete stall of disk
I/O due to a d
14 matches
Mail list logo
