Data corruption problem on USB disk

[Styno]

I'm having problems storing data on my USB disk lately. These problems result in files with zero (0) bytes length which are, of course, unreadable.

I've encountered this in different ways:
1) Upload to the FTP server
2) Moving files from one location to another on the same disk
3) Copying files from my laptop to the HD using Samba.

The only way of transferring files to the USB disk without any errors has been running 'wget' on the router itself. But I haven't used this method as extensively as the other methods, so this could just be luck.

On one particular occasion I downloaded a file with wget. Once it was transferred I could open it. Then I moved it to another location using Samba and I was still able to open it. After 10 minutes I tried to open it again but the file had changed to zero length and became unreadable.

I have an 160GB disk (Samsung) formatted into multiple partitions where one (159GB FAT32 partition) is used for storing the data.

Has anyone experienced similar behaviour? Should I change the partition type to ext2 perhaps? I need advice.

[petgun]

hi,
similar problems with the stupid WL-HDD autocopy function...useless, buggy

cu,
peter

[brubber]

I have some stone age experience with this problem using a USB ZIP 100. The problem occurred most of the time when there many parallel writes to to either the ZIP alone or the ZIP and an internal IDE disk. My solution at that was to avoid this kind of situation.

Furthermore a quick google shows that you're certainly not the only one with this or a similar problem. Apparently the USB implementation is not 100% in Linux. I guess you will finally find you're answer there, however then there is ofcourse still the problem of getting the right stuff on your ASUS box

http://www.ussg.iu.edu/hypermail/lin...09.3/1215.html

and one with a USB 2.0 device connected to USB 1.1 port

http://lkml.org/lkml/2004/9/29/46

and the experts are overhere I guess

http://www.spinics.net/lists/usb/threads.html

[Styno]

Thanks brubber for the links

To check which chip is the USB-IDE controller, execute the following command:

cat /proc/scsi/usb-storage-0/0

This gives me:

Host scsi0: usb-storage
Vendor: Genesyslogic
Product: USB Mass Storage Device
Serial Number: None
Protocol: Transparent SCSI
Transport: Bulk
GUID: 05e307020000000000000000
Attached: Yes

The chipset manufacturer is Genesys Logic.

I found the following info on Genesys Logic USB-IDE controllers:

> Hello,
> When I try to use my external h/d under Suse 9.0 I get
> the following errors
>
> usb_control/bulk_msg: timeout
> SCSI Disk Errors
> I/O Errors
>
> This happens when I open yast2 to partition the drive.
> I can see and edit the disk, the errors happen when I
> apply the changes. I can format and use this drive
> fine with Windows.
>
> I read this information regarding max_sectors
>
> "Some devices can only transfer 64 KB or less at a
> time. The most notable example is the suite of USB-IDE
> adapters made by Genesys Logic. According to their
> technical support staff transfers should be limited to
> 32 KB (max_sectors = 64), and usb-storage
> automatically sets max_sectors to this value when it
> detects a Genesys Logic device. However people have
> had no trouble using 64 KB transfers (max_sectors =
> 128), and that's what Windows uses. You can always
> increase the value above 64 using sysfs, but don't go
> beyond 128 as Genesys Logic devices are known to fail
> when transferring more than 64 KB."
>
> The controller is Gensys Logic...

There is a 2.4 patch for Genesys chips available here:

https://lists.one-eyed-alien.net/pip...ly/000583.html

I don't know it hasn't been added to the standard kernel yet...

Alan Stern

I don't know how to check if my kernel has been patched though.

There's another solution/possibility. Aparently I can echo (as root):

echo 64 > /sys/block/sdb/device/max_sectors

But I don't have /sys... Anyone an idea where I can find this?

Executing the above command might also lead to a higher throughput to/from the disk...

[Oleg]

I don't know how to check if my kernel has been patched though.

I've applied patch to custom kernel, it will appear in the next release

[Styno]

Thanks a lot Oleg, i'll be anxiously waiting

[Styno]

The problem is bugging me much.

I copied a cd image to a directory. Once succesfully finished, I copied another cd image to the same directory. Now the first cd image has 0 bytes length. When I copied cd image 1 again (succesfully), cd image 2 has 0 length.... Grrr....

Anyway, as a warning to other users:

Do not use external casings containing Genesys Logic USB converter chips

If you own an external casing with this brand of USB converter chip installed, try to return it to the shop and change it to another brand. The Genesys Logic USB chips are known to be flawed. It's only unlucky that these problems only occur using Linux...

[WlanMan]

Hmm

If windows uses the so-called not supported 64k blocks and it works, but under linux not it´s strange. Cases with Genesis Chips had been tested by the German c´t and rated very good in transfer rates. No errors were reported.

My case has a genesis chip too, the newer "e" Revision if i think right which should be optimized and hopefully bugfixed ??

Greets

[Styno]

Even Genesys Logic engineers state that the controllers are guaranteed to work perfectly when only data sizes of 32k are used. Windows (and MacOS) uses 64k by default which goes well. Linux however uses block sizes 128k (or greater) by default which does not work flawlessly with these controllers.

There is a patch developed for the 2.6.5 Linux kernel which has been downported to 2.4.x. This patch reduces data blocks to 32k for Geneys Logic chips.

The drives may perform very well under Windows (I assume C'T tested under Windows), they do NOT under the linux version used by this router (wait until the next firmware to fix this). Thats why I'm warning not to use these casing with these chips...

[Oleg]

Styno, try 1.8.1.7-2-pre1 firmware.

[Styno]

Thanks a lot Oleg for your quick reaction, much appreciated!

I've upgraded now from 1.7.5.9 CR5 to the one above: Wow, major difference. I needed to change/modify most of my scripts before things started working again. I'm now in the progress of testing the reliability of the USB HDD.

So far it seems that the USB transfer rate has gone down a bit.

Question: The mountpoint of the 1st partition is: /tmp/harddisk. Is this permanent (throughout the 1.8.x.x series firmware) or because of the beta version?

[Styno]

Oleg, after some days testing, your patched kernel seems to solve the problem, there were no more errors on new files.

I've connected the USB disk to my Windows machine and because Windows Scandisk isn't repairing my FAT32 tables , I downloaded a demo of another disk examiner/repairer which is now trying to recover existing files and FAT tables. The info this program is giving shows that Windows is also using 32k transfers to the USB disk while it uses 128k transfers to normal IDE disks. This confirms the patch you applied to the Linux kernel.

Hopefully I can do the final tests tonight (with repaired FAT tables).

[Oleg]

Ok, probably dosfsck should be included to the firmware.