Daniel Smolik wrote:
> Stefan Richter napsal(a):
>> Daniel Smolik wrote:
>>> I have external enclosure with disk (Prolific chipset) I must upgrade
>>> firmware to get it working with 2.6.x kernels. And with serialize_io=1
>>> I get ~35Mb/s writing speed. With serialize_io=0 ~ 45Mb/s but disk
>>> after copying 500MB freeze I must unplug it.
[...]
> Copying process stops and amber led
> on disk stop blinking. After while kernel transmit this:
>
> 54 marvin kernel: command: cdb[0]=0x2a: 2a 00 00 4d eb 77 00 00 f8 00
> Jul 6 22:34:04 marvin kernel: sd 9:0:0:0:
> Jul 6 22:34:04 marvin kernel: command: cdb[0]=0x0: 00 00 00 00 00 00
> Jul 6 22:34:04 marvin kernel: sd 9:0:0:0:
> Jul 6 22:34:04 marvin kernel: command: cdb[0]=0x2a: 2a 00 00 4d ec
> 6f 00 00 f8 00
[...]
> Jul 6 22:34:24 marvin kernel: sd 9:0:0:0: scsi: Device offlined - not ready
> after error recovery
[...]
I suppose there were also messages from sbp2 about command abortion
(i.e. command time-out) in dmesg.
> With Mb/s i mean MByte/s sorry.
Then that's quite a lot. Raw block I/O performance of IEEE 1394a HDDs is
in practice somewhere between 20...25 MByte/s under Linux. I get up to
23 MByte/s as measured by hdparm. More is possible with 1394b/S800 but
the Prolific chips are 1394a only AFAIK. 1394a performance under Linux
is measurably less than under Windows or Mac OS because we did not yet
implement so-called gap count optimization.
> But this night I upgrade from 2.6.16.16 to 2.6.17.1 and use full
> workaround=0xF and copying work and disk don't freeze. I do more
> testing and send result.
Interesting. The ieee1394 subsystem changes from 2.6.16.x to 2.6.17 do
not affect data transfer stability AFAIU. Maybe changes outside of the
subsystem have positive effects.
Also, sbp2's workarounds flags are not related to transfer stability,
except perhaps the 128kB max transfer flag: If this flag is kept off
_and_ the parameter max_sectors is considerably increased (it's default
value actually means 128kB maximum transfer size too), the SBP-2
protocol overhead for large I/Os -> the frequency of sent commands ->
the frequency of accidently lost commands should theoretically be
somewhat lower.
[Note to people who experiment with sbp2's workarounds: The "fix
capacity" flag should not be used unless block errors at the very end of
the disk occur (because the disk's firmware reported one block too many
as capacity value). The flags for inquiry and mode page are only related
to device recognition.]
--
Stefan Richter
-=====-=-==- -=== --===
http://arcgraph.de/sr/
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
|
