From: Douglas Gilbert <dgilbert@interlog.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
Pai <vpai@akamai.com>
Cc: ~t@akamai.com, linux-scsi@vger.kernel.org, ~c@akamai.com
Subject: Re: [RFC Patch]: scsi: sysfs file cache_type not in sync with mode page
Date: Fri, 06 Jun 2014 21:49:13 -0400 [thread overview]
Message-ID: <53926F99.4030003@interlog.com> (raw)
In-Reply-To: <1402095314.2207.105.camel@dabdike.int.hansenpartnership.com>
On 14-06-06 06:55 PM, James Bottomley wrote:
> On Fri, 2014-06-06 at 17:14 -0400, Pai wrote:
>> Hi All,
>>
>> I noticed that the sysfs file cache_type is not is sync with the information in the mode page. If we change the WCE attribute in the mode page (sdparm --set=WCE /dev/sda and sdparm --clear=WCE /dev/sda) it does not reflect this in the sysfs file.
>>
>> $ cat /sys/block/sda/device/scsi_disk/6\:0\:0\:0/cache_type
>> write back
>>
>> $ sdparm --clear=WCE /dev/sda
>> /dev/sda: TOSHIBA AL13SEB600 0101
>>
>> $ cat /sys/block/sda/device/scsi_disk/6\:0\:0\:0/cache_type
>> write back
>>
>> Ideally cache_type should have changed to 'write through' or 'none'. I have a small one line change that can fix this one. This patch applies against the latest branch "linux-3.15-rc8".
>>
>> Few things to note:
>> 1. revalidate_disk() also reads a whole bunch of other things from the mode page and I don't know if this will have any side effects. This call is made on store_cache_type as well, so I think it should be OK.
>> 2. This is extra work which is not needed in most cases (mode pages hardly change). Is there an event that we can subscribe to when the modpages change?
>>
>> Please review.
>>
>> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
>> index efcbcd1..5b65ccc 100644
>> --- a/drivers/scsi/sd.c
>> +++ b/drivers/scsi/sd.c
>> @@ -256,6 +256,7 @@ static ssize_t
>> cache_type_show(struct device *dev, struct device_attribute *attr, char *buf)
>> {
>> struct scsi_disk *sdkp = to_scsi_disk(dev);
>> + revalidate_disk(sdkp->disk);
>> int ct = sdkp->RCD + 2*sdkp->WCE;
>>
>> return snprintf(buf, 40, "%s\n", sd_cache_types[ct]);
>
> The behaviour you describe is correct. The cache type is probed once at
> init. If you change the cache behind the back of the linux code, you
> have to expect that we won't see it. We're definitely not doing a
> revalidate on every write just in case, so by extension we expect that
> to see it via sysfs either you change it through the provided interface
> (writing to the cache_type file) or you inform the kernel if you change
> it via other means by issuing the BLKRRPART ioctl.
Have a look at
echo "write through" > /sys/class/scsi_disk/6\:0\:0\:0/cache_type
and/or
echo "write back" > /sys/class/scsi_disk/6\:0\:0\:0/cache_type
and those strings can be prefixed by "temporary ". The explanation
and mapping to T10 terms is in drivers/scsi/sd.c cache_type_store(),
or at least should be.
Doug Gilbert
next prev parent reply other threads:[~2014-06-07 1:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-06 21:14 [RFC Patch]: scsi: sysfs file cache_type not in sync with mode page Pai
2014-06-06 22:55 ` James Bottomley
2014-06-07 1:49 ` Douglas Gilbert [this message]
2014-06-10 0:16 ` Vishwanath Pai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53926F99.4030003@interlog.com \
--to=dgilbert@interlog.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=linux-scsi@vger.kernel.org \
--cc=vpai@akamai.com \
--cc=~c@akamai.com \
--cc=~t@akamai.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).