Damien Le Moal <dlemoal@xxxxxxxxxx> writes: > Yes. Many embedded systems and people using old PCs still use that. > And that is not the only case. Port multiplier is the other major one since > multiple drives share the same link. In both cases, the drive "think" it is > talking to its own port, but the port is used to manage several devices. One > consequence of this is that the link speed for the port MUST be limited to the > lowest link speed of all devices. And to discover that, one has to probe all 15 > ports of the PMP to discover the devices attached... Hence the fact that > bypassing revalidation being a really bad idea. Really? I thought that the PMP recieved the FIS on the upstream port, buffered it, then sent it to the downstream port, and that could be at a different speed. So you could have a FBS PMP that is taking 3 Gbps in on the upstream link, and splitting the FISes out to two different downstream links at 1.5 Gbps. Or does that only happen with SAS switches? I think the last time I had a PATA drive was before 2006. It's really hard to believe that anyone is still using them nearly 20 years later. > Patching udisk and smartd would be a lot more sensible. An application using > passthrough to talk to a drive without first checking if the drive is actually > active is not a sensible thing to do. Especially considering that runtime They already do that. The problem is that even checking to see if the drive is running with CHECK POWER CONDITION causes libata to wake up a drive from SLEEP ( not STANDBY ) so that it can feed the drive the command. Thus why I patched libata to just complete the command without waking the drive and tell user space that it is in standby. Likewise, when the filesystem issued a FLUSH CACHE while the drive is in SLEEP, libata can just complete the request and ignore it, since there isn't anything dirty in the cache.
