On Fri, Sep 30, 2011 at 5:48 PM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 2011-09-30 at 12:26 +0530, Amit Sahrawat wrote: >> Now, for the USB HDD which do have write cache - sginfo is showing >> them to Write Cache Enabled as false. >> Why do the result of hdparm identification and sginfo varies- (I know >> they have different interface to work with and hdparm takes care of >> that by using SG_IO interface from it's code)? hdparm showed me >> correct results - that lead me to digging in the kernel code and >> checking the performance for USB HDD with Write cache enabled/disabled >> - which also showed that QUEUE ordering chosen for USB HDD is not >> correct. > > Well, what all this means is the SATL in the USB device is implemented > wrongly. Since USB devices only preset SCSI interfaces, that's what we > have to believe. > > hdparm when used correctly sends an ATA inquiry command wrapped in an > ATA_12 or ATA_16 SCSI command. A large number of legacy SATLs are known > to crash on these commands. > > Are you sure the ATA command is reporting correctly? A write back cache > is a remarkably silly thing to enable for a USB device because they're > highly likely to be surprise ejected which powers the device down. > In addition to the problem reported - there is one more thing I have noticed with USB HDD - they should be shown as 'removable' but the removable is marked only for USB PEN Drives. This seems to be a bit of confusing, any mass storage media connected on USB port should be recognized as removable. So, for handling the issue, I would consider adding the handling in slave_configure()(usb/storage/scsiglue) which marks the HDD/pen drives as removable also signifying them to be USB based. Then, as part of sd_revalidation – how about adding the ATA_IDENTIFY command part if the device is USB HDD? As far as the result of ATA_IDENTIFY is concerned – they return proper ‘256’ bytes - response and the Words – 82, 85 used for feature supported and enabled/disabled returns proper values for the USB HDD’s I have seen. In case of USB pen drives – they return failure – I did not see any crash – maybe I don’t have one of the legacy SATL based disk. Since, I am new to this – I will check more on this to get a viable solution. Please add your opinion. Can you share the name of the device which causes crash with these ATA commands, If I am able to get one I can try on that also. >> I have a large number of USB HDD's - with different vendors, and for >> all of them - it is showing Write Cache Enabled as false. >> The code works only for the Pen Drives or the USB HDD which do not >> have internal cache. >> >> Also, for journalling filesystem being used on USB HDD - it does >> becomes a cause of concern. >> >> Please share your opinion, I guess we need a change for mode sensing >> in the kernel code for USB HDD. > > Well that's a nastily complex problem. It really needs to be > whitelisted in the USB stack, but if every drive is doing it, that's > quite a task. > > The question becomes how do we detect in a SCSI fashion that the device > has a write back cache if none of the standard SCSI mechanisms reports > it? As far as detecting in SCSI fashion – I wonder using that I would have never reached the conclusion that it is the Write Cache of USB HDD which is causing problem instead I would have been focusing on particular file system (XFS in my case –which in itself is complex) – there BARRIER support and also the Queue handling in the elevator with I/O scheduler. None of the sg utils is showing anything related with the Write Cache in USB HDD – which provide any hint that the Cache is enabled – this is a bit surprising because most of the high end USB mass storages device in the market have Write Cache in them. Thanks & Regards, Amit Sahrawat > > James > > > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
