RE: [PATCH 0/5] Feature enhancements for ses module

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Doug, 

I am not sure whether I fully understand the scenario. Actually patch 5 tries to clear all reserved bits:

+ dest_desc[0] = 0;
+ /* only clear byte 1 for ENCLOSURE_COMPONENT_DEVICE */
+ if (ecomp->type == ENCLOSURE_COMPONENT_DEVICE)
+   dest_desc[1] = 0;
+ dest_desc[2] &= 0xde;
+ dest_desc[3] &= 0x3c;

Would this work for device that rejects request with 1 in RESERVED areas? 

Thanks,
Song

> -----Original Message-----
> From: Douglas Gilbert [mailto:dgilbert@xxxxxxxxxxxx]
> Sent: Wednesday, October 22, 2014 3:29 PM
> To: Jens Axboe; Song Liu; linux-scsi@xxxxxxxxxxxxxxx
> Cc: Hannes Reinecke; Dan Williams; Christoph Hellwig
> Subject: Re: [PATCH 0/5] Feature enhancements for ses module
> 
> On 14-10-22 09:12 PM, Jens Axboe wrote:
> > On 08/25/2014 11:34 AM, Song Liu wrote:
> >> From: Song Liu [mailto:songliubraving@xxxxxx]
> >> Sent: Monday, August 25, 2014 10:26 AM
> >> To: Song Liu
> >> Subject: [PATCH 0/5] Feature enhancements for ses module
> >>
> >> These patches include a few enhancements to ses module:
> >>
> >> 1: close potential race condition by at enclosure race condition
> >>
> >> 2,3,4: add enclosure id and device slot, so we can create symlink
> >>         in /dev/disk/by-slot:
> >>    # ls -d /dev/disk/by-slot/*
> >>      /dev/disk/by-slot/enclosure-0x5000ae41fc1310ff-slot0
> >>
> >> 5: add ability to power on/off device with power_status file in
> >>     sysfs.
> 
> Had a rude awakening with sg_ses recently when setting a field in the
> enclosure control dpage. That is what is being done in point 5: above.
> 
> The time honoured technique is to read the corresponding enclosure status
> dpage, find the correct element, twiddle the field of interest, set the SELECT bit
> and write it back. The idea is maintain any other field settings in that element.
> And this is what the ses module does.
> 
> There is at least one SES device out there that rejects the write if there are bits
> set in RESERVED locations. According to SPC-4 a device may do that. Look at
> the status (read) and control (write) variants of each element type: many times
> the control variant has less fields.
> 
> To fix that the read-modify-write cycle needs to be changed to a read-mask-
> modify-write cycle where the "mask" is the allowable write mask (there would
> be one for each element type).
> 
> This is ugly and may create problems in the future if and when
> T10 adds a new field in an element. About that time T10 should think about
> refining the meaning of RESERVED in SES to outlaw SES devices creating this
> particular time waster.
> 
> Doug Gilbert
> 
> >> Dan Williams (4):
> >>    SES: close potential registration race
> >>    SES: generate KOBJ_CHANGE on enclosure attach
> >>    SES: add enclosure logical id
> >>    SES: add reliable slot attribute
> >>
> >> Song Liu (1):
> >>    SES: Add power_status to SES enclosure component
> >
> > Guys, where are we with these? Seemed like they got reviewed (and
> > updates/fixes posted), then nothing else happened. Would be nice to
> > get these upstream, so we don't have to carry them at FB.
> >

--
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux