Comment 61 for bug 61235

I had a Seagate 3.5-inch Pushbutton Backup External Hard Drive (750 GB) connected to my server that had always worked perfectly. Then I connect a Seagate FreeAgent Pro (750 GB) to the same server and I started seeing the bugs described here. The bugs occur just on the new connected drive (the FreeAgent Pro). My explanation to the bug is completely different from what I read here and maybe, if I am right, I may help the kernel guys solve the problem.

Both these drives have a feature that will turn them off if they are not accessed for 15 minutes, I believe. When I access the Pushbutton backup drive after a long time without accesses I am used to see a little delay (a few seconds) on the first access. A simple ls may take 3 to 5 seconds. After that first access, everything behaves as expected. No messages on log or console screen shows up in this situation. But on the new drive, after a long period without access followed by a single access, a message showing that the drive is not ready shows up, and after a few retries, the drive is mounted as read-only. By the way, I am not running Ubuntu, but an old Fedora version that I do not reboot for about a year.

To be more specific, the message is:

sd 12:0:0:0: Device not ready: <6>: Current: sense key: Not Ready
   Additional sense: Logical unit not ready, initializing cmd. required
end_request: I/O error, dev sdd, sector 276824143
EXT3-fs error (device sdd1): ext3_get_inode_loc: unable to read inode block - inode=17301522, block=34603010
Aborting journal on device sdd1.

My explanation to that error is that on the first drive (Pushbutton backup drive), after the drive being turned off due to the 15 minutes without access, when the new access occurs, the status returned by the USB device is something like “command being processed, wait”. The kernel likes it, waits the 3 or 5 seconds, and the command is processed normally. But on the second drive (Seagate FreeAgent Pro) the status returned is “not ready”. The kernel retries a few times, but as the drive takes a long time to become ready (3 to 5 seconds) the error condition occurs.

When the drive is operational, the size of the file being copied does not matter. A few bytes or 40 Gbytes works perfectly. After a long delay without access, just a few bytes create the error condition. My main point is that the drive returns a “not ready condition” when it should return something like “wait” or “command being processed”. Unfortunately I do not have the necessary knowledge to trace the USB commands and responses in both cases, and figure out the differences, so that description is a guess.