Tejun!
Tejun Heo пишет:
I think you are not right here. If we are talking about EMI problems I
can say that the strategy of many retries is worse than one read of port
present status. EMI noise occurs at the time while software tries to
re-establish connection with empty link because there is no link
terminatiion. It's just like a car engine that has lost its muffler. It
produces lots of noise. It is better to turn the link off as soon as we
know there is no device on the port. That's why retries should last only
until that state is reported by hardware. And I think hardware reports
that state much faster than in 15 or even 5 seconds. In ICH9 it reports
this just immediately.
Not all EMIs are one-shot events. Some can span seconds. Links don't
always come up right after failures. Sometimes they require more than
one hardresets to get back to working order. Link status report is
not reliable. Sometimes they report offline for a while after certain
events. If you know how to work around the above problems under a
second, I'm all ears but I doubt it unless it involves an additional
mechanical switch.
Well, for example, USB devices have a pull-up resistor on their D+ line.
DC bias can be used for detection of device presence without mechanical
switch.
I don't know of a practical downside to lingering for limited amount
of time. If you know one, please let me know.
Ok.
Ok. So, one more question. How can I know exactly when device deletion
has completed after sending this command? For example, consider that
there some data in cache that needs 3 seconds to be sync-ed to disk. How
can I know that I must wait for 3 seconds before a can actually remove
the drive? Should I check the presence of some other filename in
/sys/block/sdX/ or do something else?
The echo to delete node is synchronous. It will return after the
device is completely removed but please note that "removing" in this
sense only covers the device itself. It will flush the request queue
and spin the drive down but won't do anything about filesystems. You
need to unmount first. hal and desktop stuff already do the right
thing for devices marked removable.
Ok, but two more questions:
1. Is there any generic mechanism of notifiing processes which had
previously opened device being deleted of this event? What will happen
to such processes? Is it possible to check who are those who uses the
drive at the moment?
2. If the drive was deleted is it possible to start it back without
physical re-connection? Can I simulate status change og that port to
force the driver to auto-detect block device?
PS: as for this:
I'll be happy to improve EH behavior but you need to come up with better reasons.
I can tell that for me enclosure management support is quite a good
reason. Unfortunately, there is no this support in official kernel. I
have seen only limited support of activity LED in kernel 2.6.28.
However, I am using Debian where the latest kernel is only 2.6.26. As a
result I had to write a simple ahci_em module which register simple proc
interface to send LED states to all ICH9 ports. However, final goal is
to integrate this module with mdadm to have proper indication of RAID state.
Best regards, Vladimir Dashevsky
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
