From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Christoph Hellwig <hch@infradead.org>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
Dmitry Monakhov <dmtrmonakhov@yandex-team.ru>
Subject: Re: [PATCH] drivers/ata: print trim features at device initialization
Date: Sun, 09 Jun 2019 14:37:21 -0700 [thread overview]
Message-ID: <1560116241.3324.19.camel@HansenPartnership.com> (raw)
In-Reply-To: <048ed77f-8faa-fb67-c6bc-10d953f52f89@yandex-team.ru>
On Sat, 2019-06-08 at 17:13 +0300, Konstantin Khlebnikov wrote:
> > On 08.06.2019 11:25, Christoph Hellwig wrote:> On Fri, Jun 07, 2019
> > at 10:34:39AM +0300, Konstantin Khlebnikov wrote:
> > >
> > > Do we really need to spam dmesg with even more ATA crap? What
> > about
> > > a sysfs file that can be read on demand instead?
> > >
> >
> > Makes sense.
> >
> > Trim state is exposed for ata_device:
> > /sys/class/ata_device/devX.Y/trim
> > but there is no link from scsi device to ata device so they hard to
> > match.
> >
> > I'll think about it.
>
> Nope. There is no obvious way to link scsi device with ata_device.
> ata_device is built on top of "transport_class" and
> "attribute_container".
> This some extremely over engineered sysfs framework used only in
> ata/scsi. I don't want to touch this.
You don't need to know any of that. The problem is actually when the
ata transport classes were first created, the devices weren't properly
parented. What should have happened, like every other transport class,
is that the devices should have descended down to the scsi device as
the leaf in an integrated fashion. Instead, what we seem to have is
three completely separate trees.
So if you look at a SAS device, you see from the pci device:
host2/port-2:0/end_device-2:0/target2:0:0/2:0:0:0/block/sdb/sdb1
But if you look at a SATA device, you see three separate paths:
ata3/host3/target3\:0\:0/3\:0\:0\:0/block/sda/sda1
ata3/link3/dev3.0/ata_device/dev3.0
ata3/ata_port/ata3
Instead of an integrated tree
Unfortunately, this whole thing is unfixable now. If I integrate the
tree properly, the separate port and link directories will get subsumed
and we won't be able to recover them with judicious linking so scripts
relying on them will break. The best we can probably do is add
additional links with what we have.
To follow the way we usually do it, there should be a link from the ata
device to the scsi target, but that wouldn't help you find the "trim"
files, so it sounds like you want a link from the scsi device to the ata device, which would?
James
next prev parent reply other threads:[~2019-06-09 21:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-07 7:34 [PATCH] drivers/ata: print trim features at device initialization Konstantin Khlebnikov
2019-06-07 16:58 ` Martin K. Petersen
2019-06-08 9:12 ` Konstantin Khlebnikov
2019-06-08 14:13 ` Konstantin Khlebnikov
2019-06-09 21:37 ` James Bottomley [this message]
2019-06-10 7:49 ` Konstantin Khlebnikov
2019-06-10 22:48 ` James Bottomley
2019-06-14 13:49 ` Konstantin Khlebnikov
2019-06-14 14:54 ` James Bottomley
2019-06-08 8:25 ` Christoph Hellwig
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=1560116241.3324.19.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=axboe@kernel.dk \
--cc=dmtrmonakhov@yandex-team.ru \
--cc=hch@infradead.org \
--cc=khlebnikov@yandex-team.ru \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.petersen@oracle.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).