reviewed the hardware this morning and did a firmware-upgrade on the 9550SXU to 3.08xxxx. Maybe this speeds things up...
Processor: Opteron 285
mem: 8GB
Cheers
Matthias
Printable View
reviewed the hardware this morning and did a firmware-upgrade on the 9550SXU to 3.08xxxx. Maybe this speeds things up...
Processor: Opteron 285
mem: 8GB
Cheers
Matthias
Well..
That dindn't helped..
still getting cmd_abort and
XFS: bad magic number
XFS: SB validate failed
attempt to access beyond end of device
dm-6: rw=0, want=354, limit=352
isofs_fill_super: bread failed, dev=dm-6, iso_blknum=88, block=176
UDF-fs: No VRS found
XFS: bad magic number
XFS: SB validate failed
looks like I'll trash Open-e and use GNBD, since I need a working solution..
cheers
Matthias
Okay, I guess I'm kind of necro-bumping an old post, but we have a customer who is getting lots of these cmnd_abort(1143) errors. They are using the old build 3278. Obviously, the Atlanta build uses a different iscsi target framework by default (it uses SCST vs. old IET). So, this will most likely fix the problem, right?
(Also, we're making the changes suggested in the knowledge base article regarding buffer lengths for the iscsi target.) We are also enabling disk write cache, which we've seen to GREATLY increase performance when using 7200rpm drives and the Areca 1680 controller (rebuild times decrease by a full order of magnitude).
I saw this link - could be something.
https://forums.openfiler.com/viewtopic.php?id=1654
Yeah, this seems to confirm it. open-filer uses IET, I believe. While googling, I only really saw "cmnd_abort(1143)" when refering to IET. So, either this issue isn't a problem for SCST or SCST gives a different error name/number. Good to know!
Correct, they use IET as well and we now use SCST - though we have IET as well that is switchable.