Here is a rough patch to add libata transport attributes, along the
lines of fibre channel and parallel scsi. I wrote it as it seemed to be
the cleanest way of extracting ata-specific information (currently drive
model, serial number and firmware revision) from sysfs (in
/sys/class/libata_transport/). There are a few issues, in particular:
1. it wont compile modular, as libata depends on scsi_transport_libata
and vice-versa at the moment. I am not sure how you are supposed to get
around this (and there arent any significant number of drivers in tree
using the transport modules yet).
2. It would be nice if the device directory in sysfs had a symlink to
the transport attributes directory, not just the other way round.
3. I couldnt work out what scsi_transport_template.size was the size of,
as I couldnt see where it was used anywhere...
patch against 2.6.5-rc3-libata1 but probably applies against most recent
kernels.
Justin Cormack
Justin Cormack wrote:
> Here is a rough patch to add libata transport attributes, along the
> lines of fibre channel and parallel scsi. I wrote it as it seemed to be
> the cleanest way of extracting ata-specific information (currently drive
> model, serial number and firmware revision) from sysfs (in
> /sys/class/libata_transport/). There are a few issues, in particular:
>
> 1. it wont compile modular, as libata depends on scsi_transport_libata
> and vice-versa at the moment. I am not sure how you are supposed to get
> around this (and there arent any significant number of drivers in tree
> using the transport modules yet).
>
> 2. It would be nice if the device directory in sysfs had a symlink to
> the transport attributes directory, not just the other way round.
>
> 3. I couldnt work out what scsi_transport_template.size was the size of,
> as I couldnt see where it was used anywhere...
>
> patch against 2.6.5-rc3-libata1 but probably applies against most recent
> kernels.
Did you see the comments I posted WRT mort's patch?
Since libata is leaving SCSI in 2.7, I would rather not add superfluous
stuff like this at all.
Further, you can already retrieve the information you export with _zero_
new code.
Jeff
On Wed, 2004-03-31 at 22:07, Jeff Garzik wrote:
> Did you see the comments I posted WRT mort's patch?
>
oops, no I missed his patch and your comments until now.
> Since libata is leaving SCSI in 2.7, I would rather not add superfluous
> stuff like this at all.
>
I didnt know this.
> Further, you can already retrieve the information you export with _zero_
> new code.
How? Sorry to be dumb...
Justin
Justin Cormack wrote:
> On Wed, 2004-03-31 at 22:07, Jeff Garzik wrote:
>
>
>>Did you see the comments I posted WRT mort's patch?
>>
>
>
> oops, no I missed his patch and your comments until now.
>
>
>>Since libata is leaving SCSI in 2.7, I would rather not add superfluous
>>stuff like this at all.
>>
>
>
> I didnt know this.
>
>
>>Further, you can already retrieve the information you export with _zero_
>>new code.
>
>
> How? Sorry to be dumb...
Obtain the SCSI inquiry info from userspace...
Jeff
On Thu, 2004-04-01 at 19:10, Jeff Garzik wrote:
> Justin Cormack wrote:
> > On Wed, 2004-03-31 at 22:07, Jeff Garzik wrote:
> >
> >
> >>Did you see the comments I posted WRT mort's patch?
> >>
> >
> >
> > oops, no I missed his patch and your comments until now.
> >
> >
> >>Since libata is leaving SCSI in 2.7, I would rather not add superfluous
> >>stuff like this at all.
> >>
> >
> >
> > I didnt know this.
> >
> >
> >>Further, you can already retrieve the information you export with _zero_
> >>new code.
> >
> >
> > How? Sorry to be dumb...
>
> Obtain the SCSI inquiry info from userspace...
I looked at doing this, but unfortunately this doesnt work due to
incompatibilities between the SCSI and ATA way of doing things. The ATA
product ids are truncated from 20 chars to 16 (there is no separate
vendor ID so both are effectively combined into one field with arbitrary
layout). The product revision level is only 4 bytes in scsi, unlike the
8 byte firmware revision in ATA. You can get the serial number though.
Currently you use ATA as vendor id, I will quite happily patch libata to
stick the whole ATA identify into some EVPD scsi inquiry pages as vendor
specific info and write a userspace tool to parse it if you would
rather. Thats much easier to junk when you move out of scsi-world and
presumably start to export native sysfs info.
Justin
Jeff Garzik wrote:
> Since libata is leaving SCSI in 2.7, I would rather not add superfluous stuff like this at all.
> Further, you can already retrieve the information you export with _zero_ new code.
does this include informations about the drives SMART status, too?
The smartmotools (http://smartmontools.sourceforge.net/) won't work
with libata until some "passthrough" command gets implemented :-(
Will this be available soon (or even working now), or do I have to
wait until 2.7?
This is the main reason, that prevents me from switching to SATA now!
Just when writing these lines, I'm analyzing some prefail indications
from one of my 300G PATA disks via SMART. I have no problem, to replace
that disk now, but when running those disks blindly without SMART over
SATA, I certainly would loose those 300G very soon...
So, can you give us an idea of a time line about those things, please?
Dieter.
--
Dieter St?ken, con terra GmbH, M?nster
[email protected]
http://www.conterra.de/
(0)251-7474-501
Dieter Stueken wrote:
> Jeff Garzik wrote:
>
>> Since libata is leaving SCSI in 2.7, I would rather not add
>> superfluous stuff like this at all.
>> Further, you can already retrieve the information you export with
>> _zero_ new code.
>
>
> does this include informations about the drives SMART status, too?
No. SMART would not be appropriate for a transport attribute either.
> The smartmotools (http://smartmontools.sourceforge.net/) won't work
> with libata until some "passthrough" command gets implemented :-(
> Will this be available soon (or even working now), or do I have to
> wait until 2.7?
Soon.
Jeff