Description of problem: The USB storage cannot use <2TB. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. connect USB storage of over 2TB. 2. 3. Actual results: All capacity can be used. Expected results: Capacity is cut off with 2TB. dmesg ================================================================== Initializing USB Mass Storage driver... scsi1 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 4 usbcore: registered new driver usb-storage USB Mass Storage support registered. usb-storage: waiting for device to settle before scanning Vendor: ST315003 Model: 41AS Rev: SD1A Type: Direct-Access ANSI SCSI revision: 05 sde : very big device. try to use READ CAPACITY(16). sde : READ CAPACITY(16) failed. sde : status=0, message=00, host=5, driver=00 sde : use 0xffffffff as device size ================================================================== Additional info: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=commitdiff;h=17f060224fb9f435c6f9306b7b61419d038def13
Created attachment 382443 [details] Test patch 1 Exactly the same as referenced in the report.
I have built a test kernel. Requestor, please download and test kernel 2.6.18-183.el5.bz503864.1 from this URL: http://people.redhat.com/zaitcev/ftp/503864/ I have reviewed the related code and although it's a far cry from upstream, it appears to have everything necessary otherwise. But testing is required nonetheless.
*** Bug 568797 has been marked as a duplicate of this bug. ***
Created attachment 398696 [details] Test patch 2 - includes FireWire
I have lost my test setup for the time being, as the drive got deployed in eSATA mode on another server (will use it via NFS mount for now). Ran out of time for something needed for a client. I'll see about finding a way to test with another drive, might take a few days (might have to retrieve one from a data center). The 4TB did run into trouble when we took it, with file system on it, to the data center, and tried it on eSATA. Got indications of writing past the end of the physical device, like the ext3 thought the drive was bigger than it was. I don't know if that's because the person who created the partition screwed up, or if it was in fact a problem related to this bug. I suggest holding this open until a bit more testing can be done, either by me or by someone else. Sorry for the delay.
The test kernel 2.6.18-183.el5.bz503864.2 is at the same location. This time, FireWire fix is included. Please verify that it functions. The write over the end of device indications are not acceptable. I'll need to know if that happens and receive a relevant dmesg.
Just got a 3TB drive in hand, so I can get back to testing this for you. Do you want to re-spin the test kernel before I do my testing, or use the one you already have up? (for that matter, is it still up?). I can do the testing over the next several days.
Please use the existing images from comment #10, location as in comment #6. I had to move things a bit, but it's back now.
Drive is running on USB. Deleted partition table, labeled drive, and built an ext3 using the entire volume. Now have a script running that's creating 1GB files in a directory, filling the disk to see if there are any errors about running past the end of the physical media (any other suggestions for testing this?). It is possible the write-past-end previously was due to a partition configuration error by one of my staff. Once the test is complete on USB, we'll do a cursory check on firewire for good measure. I expect filling the disk via USB is going to take most of the weekend though. I won't clear the needinfo until I have the test results.
Thanks a lot, this is good enough. I'm dropping needinfo.
The patch is posted for internal review.
Just a follow-up: Scripts completed filling the 3TB drive with data (file system set up with zero reserve) with no errors whatsoever. We will re-plug into firewire today to verify, but it looks like the patched kernel did the job well. We'll look forward to the fix hitting an upcoming RHEL 5 kernel update. Thanks for getting this resolved.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
in kernel-2.6.18-203.el5 You can download this test kernel from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed.
Just getting back to looking at this. Do you still need this tested? I think I still have a setup where I can do so. Let me know which of your test kernels contain the fix.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0017.html