SCIENTIFIC-LINUX-USERS Archives

July 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Lamar Owen <[log in to unmask]>
Reply To:
Lamar Owen <[log in to unmask]>
Date:
Wed, 2 Jul 2014 12:04:09 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (35 lines)
On 07/02/2014 11:40 AM, Andras Horvath wrote:
> Good thinking would be, but as I mentioned before, I tested this issue on several hardware. With 2 new disks, new enclosures (3 kinds but same type), on different kind of servers and with different USB cables.

That does seem to cover it quite well; while it is a bit of a long shot 
it is possible all three enclosures used the same USB to SATA bridge.  
The odd part is that if it were intrinsic to the kernel or the USB stack 
of the OS one would think other people would have seen the problem (and 
thus why you asked the list if anyone else had seen the problem....:-)).

> I think it must be the software causing this. Especially because the same hardware setup worked fine for long on Debian 6. That's why I turned to the SL mailing list.

And that's the correct course.

> So disk is ok, cable end enclosure is ok, and server hw must be too I believe.
I would tend to agree.  But there has to be something different here, 
otherwise I would think the list would be inundated with similar 
reports.  I can't directly test SL 6 in this case, since I don't have an 
active SL 6 box at the moment, but my CentOS 6.5 laptop and a couple of 
CentOS 6 servers (Dell PowerEdge 1950) we have here do large USB data 
transfers frequently without seeing your issue.  It is possible the SL 
kernel and USB stack have some differences to the CentOS kernel and USB 
stack, even being built from the same sources; I would not think that 
likely, and I would think that CentOS 6 in your circumstance should 
produce the same results.

In order to actually replicate the results we would need detailed 
information on the exact hardware that has been used that exhibits the 
problem (even down to the firmware rev of the WD hard disk), and then 
someone with that same hardware would need to replicate.  It could be 
difficult.

But if you're satisfied with the SATA connection, just use it.  I for 
one would like to find out what's actually going on, and help figure out 
how to actually fix it.

ATOM RSS1 RSS2