Writing to a Block Greater than the Number of Blocks on the USB Drive

Lately, I have been getting errors with external usb drives. The system is trying to write to a block that is greater than what is available on the disk. Most of the external usb drives that I have tried are Seagate. For example, a 2TB Seagate has 3907029167 blocks, but the system tries to write to blocks much greater than this:
Code:
GEOM_ELI: Crypto WRITE request failed (error=5). da1s1d.eli[WRITE(offset=497731796992, length=32768)]
.
g_vfs_done():da1s1d.eli[WRITE(offset=856912723968, length=32768)]error = 5
As can be seen, the requested block to write to is greater than blocks on the drive (if I understand this correctly.) I have tried various drives. I have some portable drives that have never given me this error in the past, but now it seems they are. (usually very random)

At first, I thought it was just the new Seagate usb drive with an incompatible controller that I returned to the store, but this error keeps popping up on other drives as well. Both using geli and not.

I just don't see how it could be 5 different drives failing at once. Nor do I see it as a hardware problem. It seems that there is a software issue of some sort. Maybe the usb drive software has a bug in it that tells the drive to write to a block much great than what is available.

I have scoured the internet looking for an explanation. I have seen others with the same problem and helpers saying "yep, trying to write to a block than what is available", but no explanations or solutions.

(I am running FreeBSD 9.3. It is all usb 2.0 on this older motherboard.)

What could be causing this?
 
I do believe FreeBSD 9 is no-longer supported.

Most likely this offset is in bytes, not blocks. 5 could be 5 EIO Input/output error. Some physical input or output error occurred. (see errno(2)).
 
The likely cause is a software bug, so SirDice's answer (use modern software that has fewer bugs) is spot on.
The error "5" tells you fundamentally nothing: as Bobi B said, it means EIO = error during IO: but that was obvious, we knew that already. It is completely not clear whether the error messages report the offset in bytes, sectors (which could be 512 or 4096 bytes long), or some units like file system blocks. People who write error messages really should be clearer about stuff like that, but sadly, they aren't. To figure out what those messages really mean, one should look at the source code, but in your case, that's just too much work.

Your software stack above the USB block device layer looks a little more complex than usual, with an encryption layer (GELI).

One of the error messages comes from GELI; the other one seems to be from the VFS layer (which is the topmost part of the file system in the kernel, shared by all file systems). I have a slight suspicion that the root cause is file system corruption: some file system internal metadata might contain a reference to a block address on disk which is just wrong. If that's true, a fsck might be able to cure it (but also do more damage). But the first check should be to upgrade, and see whether the problem just goes away by itself.
 
Back
Top