eSATA Sheeva, Debian Squeeze and Port Multiplication

[c128]

I've been considering upgrading my standard Sheeva to an eSATA Sheeva, and also moving my 4-Bay USB-based storage to something that supports eSATA at the same time.

Thing is...I can't quite work out what the current situation is with an eSATA Sheeva and port multiplication; if I get a 4-Bay eSATA enclosure that supports port multiplication, I want to be able to access its drives individually from the eSATA Sheeva with minimal fuss.

Assuming an eSATA Sheeva and the current vanilla install of Debian squeeze (with whatever kernel it currently ships - 2.6.32?), will eSATA port multiplication work out of the box, or will I be moving into the realms of custom-built kernels (where I don't really want to be)?

Added Later

I ought to add that I'm currently looking at one of these http://www.startech.com/product/SAT3540U2E-35in-4-Drive-eSATA-USB-Multi-Bay-External-Hard-Drive-Enclosure , but I'm flexible on the enclosure side of things if it eases things with the Sheeva.

[NewIT_Marcus]

It's my understanding that port multiplication is supported, but I can't say for sure that it will work out of the box with your hardware.

[punaniac]

I haven't personally tried, but there are a few threads reporting success, depending on the SATA controller used in the multi-bay enclosure.

see this post here on the forum or another post on plugcomputer.org forum.

best regards,
Andreas

[c128]

Thanks - I had searched over both these and the plugcomputer forums, but totally missed this post from the thread you've linked:

http://www.newit.co.uk/forum/index.php/topic,607.msg3024.html#msg3024

So - that sounds relatively positive, at least for the listed enclosure chipset, although I note the comment about the Debian kernel used being " 2.6.32.7 - the one supplied by Newit on an SD card".
Anyone know how that kernel differs from the latest vanilla Debian squeeze kirkwood kernel available from the Debian distribution itself?

[NewIT_Marcus]

FWIW, our kernels pretty much match the sheeva.with-linux.comkernels. When we first started selling the eSATA Sheevaplug we used an eSATA patch which I think was not available at sheea.with-linux, or different to theirs (theirs was originally for modified Sheevaplugs). There shouldn't be any significant difference between the two, in terms of functionality. I think that our current kernel is sheeva.with-linux.com 2.6.36, with a patch that relates to booting an eSATA plug from NAND and correctly detecting an SD card.

Debian is a slightly different matter, but I think that their kernel package isn't quite the same as normal packages (which are completely installed automatically); there may be a need to relocate a downloaded kernel and the package possibly expects the user to perform the last step manually. I think that you are reasonably safe to mix & match with the sheeva.with-linux.com kernels if you want to use them instead.

[c128]

Thanks Marcus, useful stuff.

Going to ponder this, for a bit, although I am swayed towards an eSATA Sheeva + enclosure solution.

I currently have a standard Sheeva connected via USB to one of these: http://www.amazon.co.uk/EdgeStore-DAS400-Bay-USB-Enclosure/dp/B001H54JXQ as my fileserver.

That's been fine for a long time now, over a year or so, but recently I've been getting some strange issues.  Occasionally a large file being copied over onto the Samba share of one of the drives will "take down" all of the drives.  Logging into the Sheeva itself is fine, but I can't access any of the local mountpoints for any of the drives/partitions in the enclosure, even the ones that weren't involved in the copy - none of the logging is particularly informative.  The quickest "fix" is to unplug/replug the enclosure's USB, then everything starts working again post re-mount, even on the problematic share with the same file...at least for a while, then it happens again.

Can't yet decide/work out whether it's the USB failing on the Sheeva side or the enclosure's side, although I'm guessing the latter.

[Andrew]

As the original author of

http://www.newit.co.uk/forum/index.php/topic,607.msg3024.html#msg3024

I can report trouble free operation with esata for over 7 months now.

W.r.t your USB enclosure. Do your hard drives spin down? Maybe the enclosure does this unilaterally without the knowledge of the host plug. I would see if you can turn this functionality off and see if you still get your hang issue. I had similar issues when I was trying to control USB connected drives for 24/7 operation. This was my principle reason for moving to an esata set up. I do wonder whether USB was ever really designed for 'always on' rotating mass storage (unlike the sata or ide protocols).

[c128]

Thanks for that Andrew.

I guess my current USB problems are slightly odd.  I've seen similar reports on the web, but none that seem directly related.

As background then, my USB fileserver setup has been fine for at least a year - no issues at all.
I'm running a standard Sheevaplug with Debian squeeze, and just take all the updates when they come.
I have a four bay DAS400 USB enclosure, as above, and all bays are populated with 500GB disks.

Now...about a month ago I got my first issue where copying a large-ish file over to a Samba share on one of the drives from Windows - it stopped mid-way, and then errored out.  That's what I've seen again, twice, more recently.  I say "large-ish", but the files in question were about 350-400MB, and are the sort of files I've been copying over without problem for the last year.

This is what have in /var/log/messages at the point of failure:

Code:

Jun 17 19:20:58 plug1 kernel: [268869.342387] usb 1-1: reset high speed USB device using orion-ehci and address 2
Jun 17 19:21:08 plug1 kernel: [268879.612068] usb 1-1: reset high speed USB device using orion-ehci and address 2
Jun 17 19:21:13 plug1 kernel: [268884.881907] usb 1-1: reset high speed USB device using orion-ehci and address 2
Jun 17 19:21:24 plug1 kernel: [268895.151589] usb 1-1: reset high speed USB device using orion-ehci and address 2
Jun 17 19:21:24 plug1 kernel: [268895.302115] sd 0:0:0:2: Device offlined - not ready after error recovery
Jun 17 19:21:24 plug1 kernel: [268895.308957] sd 0:0:0:2: [sdc] Unhandled error code
Jun 17 19:21:24 plug1 kernel: [268895.313876] sd 0:0:0:2: [sdc] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
Jun 17 19:21:24 plug1 kernel: [268895.321144] sd 0:0:0:2: [sdc] CDB: Write(10): 2a 40 1b 0a fc ff 00 00 f0 00 00 00
Jun 17 19:21:24 plug1 kernel: [268895.334770] __ratelimit: 37 callbacks suppressed
Jun 17 19:21:24 plug1 kernel: [268895.345886] lost page write due to I/O error on sdc1
Jun 17 19:21:24 plug1 kernel: [268895.357363] lost page write due to I/O error on sdc1
Jun 17 19:21:24 plug1 kernel: [268895.368835] lost page write due to I/O error on sdc1
Jun 17 19:21:24 plug1 kernel: [268895.380310] lost page write due to I/O error on sdc1
Jun 17 19:21:24 plug1 kernel: [268895.391787] lost page write due to I/O error on sdc1
Jun 17 19:21:24 plug1 kernel: [268895.403253] lost page write due to I/O error on sdc1
Jun 17 19:21:24 plug1 kernel: [268895.414721] lost page write due to I/O error on sdc1
Jun 17 19:21:24 plug1 kernel: [268895.426188] lost page write due to I/O error on sdc1
Jun 17 19:21:24 plug1 kernel: [268895.437654] lost page write due to I/O error on sdc1
Jun 17 19:21:24 plug1 kernel: [268895.449120] lost page write due to I/O error on sdc1
Jun 17 19:21:24 plug1 kernel: [268895.928090] JBD: Detected IO errors while flushing file data on sdc1
Jun 17 19:21:26 plug1 kernel: [268897.547852] JBD: Detected IO errors while flushing file data on sdc1

If I login then sometimes the mounted drive, sdc, is just unavailable, and sometimes it is mounted read-only.  umounting it nearly always gets a "can't because it's in use" response, and the only real way to get it working properly again is to unplug/replug the USB cable to the Sheeva.

I think the disks do spin-down in the enclosure, but I don't do anything active to control or activate this, and I certainly haven't changed anything setup-wise in this area.
I've fsck-ed the particular disk in the enclosure twice now, and it isn't showing any issues at all - it has always been the same disk, but then I use the partition there most for these large files.
I've also changed the USB cable, but more out of hope than expectation.

In all of the above I'm not sure whether to suspect the enclosure, the Sheeva USB interface, the hard disk or something else, hence my thinking about an eSATA solution with a new Sheevaplug and eSATA 4-bay enclosure.  Most postings related to the above log out suggest the drive is on its way out, but fsck doesn't seem to agree in my case.

Everything's working fine now with my current USB setup, and I've copied the last problematic file over without issue, but I just know it's waiting to go wrong again...