[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADDb1s3KjMugBGwLmjoPv93hJVBCjkD81o8F0CZxJXXt+-Fk2A@mail.gmail.com>
Date: Wed, 28 Sep 2011 21:27:23 +0530
From: Amit Sahrawat <amit.sahrawat83@...il.com>
To: linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
Christoph Hellwig <hch@...radead.org>
Subject: Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)
Marking mail to linux-scsi.
Thanks Christoph.
Regards,
Amit Sahrawat
On Wed, Sep 28, 2011 at 9:12 PM, Amit Sahrawat
<amit.sahrawat83@...il.com> wrote:
> When a USB HDD is connected to the device, it invokes slave_configure
> to configure the USB HDD. In this function, whenever there is a SCSI
> device of type TYPE_DISK, it sets:
> /* A number of devices have problems with MODE SENSE for
> * page x08, so we will skip it. */
> sdev->skip_ms_page_8 = 1;
>
> Now, as a part of SCSI device probing, in the function
> sd_revalidate_disk()-->sd_read_cache_type(), there is a condition
> if (sdp->skip_ms_page_8)
> goto defaults;
> which becomes always true for all the USB HDD’s – the net result is
> that the Write Cache is never considered for USB HDD(WCE = 0) –
> “Assuming drive cache: write through”
>
> What’s more – the QUEUE ordering which is marked for WCE=0 is
> QUEUE_ORDERED_DRAIN, instead of QUEUE_ORDERED_DRAIN_FLUSH
> This means there is no flushing of USB HDD internal cache (although
> SYNCHRONIZE_CACHE is implemented as passed as command in
> sd_prepare_flush) – queue_flush()(called in function
> blk_do_ordered()-->start_ordered()) does not gets called in case of
> QUEUE_ORDERED_DRAIN.
>
> This causes a serious impact on USB HDD’s.
>
> Please let me know in case I have missed something in my observations.
>
> Thanks & Regards,
> Amit Sahrawat
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists