All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.