Other USB drive mount failed = g_vfs_done() WRITE error = 5

[Oznaiust]

A new 2TB USB drive was mounted with FAT32 via a 10-port Hub first and worked fine until approx 1TB filled after approx 4 months. Then i could not create new directories but i could copy 3GB files into existing directories. When i tried to umount the device i got umount: unmount of /media/2 failed: Input/output error.
dmesg revealed several lines of error 5 in clusters of the lines

g_vfs_done():da2s1[WRITE(offset=-989045458944, length=32768)]error = 5
g_vfs_done():da2s1[WRITE(offset=-1098390013952, length=32768)]error = 5
g_vfs_done():da2s1[WRITE(offset=-1082101827584, length=32768)]error = 5
g_vfs_done():da2s1[WRITE(offset=-1082078693376, length=32768)]error = 5
g_vfs_done():da2s1[WRITE(offset=-1082078660608, length=32768)]error = 5
g_vfs_done():da2s1[WRITE(offset=-1082078627840, length=32768)]error = 5
g_vfs_done():da2s1[WRITE(offset=-1082078595072, length=32768)]error = 5
g_vfs_done():da2s1[WRITE(offset=-1082078562304, length=32768)]error = 5
g_vfs_done():da2s1[WRITE(offset=-1079526656000, length=32768)]error = 5
g_vfs_done():da2s1[WRITE(offset=-1079526623232, length=32768)]error = 5
g_vfs_done():da2s1[WRITE(offset=-1079526590464, length=32768)]error = 5

I rebooted the machine after doing latest updates and when i try to mount the device again with
mount -t msdosfs -o noatime /dev/da2s1 /media/2 i got no error but again if i try to create a new directory it failed and dmesg now shows a single line of:
g_vfs_done():da2s1[WRITE(offset=-985294178304, length=32768)]error = 5

I searched bugreports and forum and found some g_vfs_done related reports. I'm ashamed that i didn't test the new drive for badblocks before. I'll do that as soon as i have space to backup that drive. Until then i noticed that my offset is negative while all other reports here have positiv values. Because of the possilbe hardware failure i'll hold back a bugreport. I failed to find the list of error codes for g_vfs_done, man or apropos didn't reveal anything and www searches didn't link to a list.
Could you please point me to a list that explains what the errors 5, 6, 30 and (all?) others are?

(And if you think the negative offset is worth a bugreport regardless of a possible hardware failure please let me know.)

 

[SirDice]

I'm ashamed that i didn't test the new drive for badblocks before.

It doesn't always work with USB converters but try smartctl(8) (part of sysutils/smartmontools). No need to write anything to the drive, just read its SMART data (with the caveat that some USB converters block this).

 

[Oznaiust]

Done. It shows that the <Intenso SCSI 0209> Fixed Direct Access SPC-4 SCSI device is internally a WDC WD20SPZX-22UA7T0. All typical error counters show 0.

Many things are matching to this old history of FreeBSD 9. The main difference is that they are talking about READ errors but i have WRITE errors. The last posting there pointed to a possible problem with ehci. I greped my dmesg for ehci without findings. It's a A2SDi-8C-HLN4F with

xhci0: <Intel Denverton USB 3.0 controller> mem 0xdf560000-0xdf56ffff at device 21.0 on pci0
xhci0: 32 bytes context size, 64-bit DMA
usbus0 on xhci0

I found sysctl -d hw.usb.ehci and will try the setting of the old posting.

 

[SirDice]

All typical error counters show 0.

That's good and bad news. The good news is that the disk itself is probably just fine. The bad news is that the corruption is probably caused by the USB->SATA converter.

 

[PMc]

I searched bugreports and forum and found some g_vfs_done related reports. I'm ashamed that i didn't test the new drive for badblocks before. I'll do that as soon as i have space to backup that drive. Until then i noticed that my offset is negative while all other reports here have positiv values.

This is a good observation. It is very obvious that the system cannot write to a location that is before the beginning of the disk.
g_vfs_done() does not mean much here, this is just the normal place from where I/O errors come when writing to a filesystem. So what You have is a normal I/O error. This would point to bad-blocks (or other hw failure) if there weren't these negative numbers.
Now the first thing would be to get that msdos filesystem out of the loop. Find out if one can read that device on the raw surface below the filesytem: try to read /dev/da2 directly ( dd if=/dev/da2 of=/dev/null bs=64k - you could find out how to run dd to only read some samples, if that takes too long). It would also be interesting to see if we can write the whole thing - but then we would destroy the data that is already on it.

It is well possible that this will work, and that something in the mapping of the filesystem is hosed. vulgo: there is crap in the partition table, and FreeBSD understands it as a negative offset.
What SirDice suggests is also possible - but that should then be independent of the filesystem, and we should see these errno=5 also when accessing the raw disk.

In any case it would be advisable to get the current data off that disk, because probably the partition table will have to be recreated.

Could you please point me to a list that explains what the errors 5, 6, 30 and (all?) others are?

/usr/include/sys/errno.h