Hello, Владимир Дашевский wrote: >>> 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. >> >> SATA is not USB and onlineness detection isn't that simple. Also, >> have you tried to run a system on a USB device over flaky connection? >> > Well, I cannot argue with you here. All that I wanted to say is that I > would prefer more optimistic software behavior if the hardware really > supports device connection status. I really don't follow your train of thoughts here. Are you saying that the driver should be optimistic about the reliability about status reported by the hardware even when it is inherently imprecise (please read the spec) and real world experiments prove that? >>> 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? >>> >> >> -EIO will happen, fuser, but if you want something intelligent, hal + >> dbus. >> > Sorry, I missed the sense of this sentence. -EIO will happen to any processes trying to do IO on the removed device. fuser will find out who's using the block device but if you want something more intelligent, look at hal + dbus. > I tried this deletion with fdisk and see that fdisk does not even > comply for device failure. It just starts to print empty partition > table and so on. So the question is how to properly close any > activity concerned with device being deleted if I do not know > exactly what is that activity? Are the most typical programs which > are allowed to use raw block devices aware of unexpected block > device loss? Please take a look at how desktop guys are handling the issue. It's not something which can be handled in kernel proper. >> I don't really follow what you're trying to achieve but if you want >> some fancy snapshotting + remapping trick, the best place would be dm. >> > Well, I didn't think of any tricks. I just deleted the drive as you > taught me and tried to get it back without moving myself in front of the > server. :-) > However, I think that some call to rescan scsi devices will be useful. Ah.. in that case, you can do # echo - - - > /sys/class/scsi_host/hostN/scan >>>> 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. >>> >> >> How is that in any way exclusive against longer detach delay? > > I just answered with better reasons to make you happy, not with another > advice of detach delay. Well, I was asking for better reasons to change the detach delay. >> The biggest obstacle is that there aren't too many enclosure devices >> floating around. What kind of device are you using? >> > I don't know exactly what device are you talking about. I was talking > about LED message types that are supported in ICH9. > As for my server, ICH9 provides SGPIO interface that is routed to > 4-drive hot-swap backplane based on AMI MG9071 chip. However, this > information isn't needed to program ICH9 since the LED message mechanism > is supported in it. Other message types are not supported. And it is > very strange that linux ahci still does not support this functionality > since it was first introduced in ICH8 (datasheet first release in June > of 2006). Yeah, I know it has been in the spec but without hardware to play with it's difficult to add driver features and lack of general availability also means lower demand. > PS: My code has about 11Kb of text and supports all useful RAID states: > NORMAL, LOCATE, REBUILD, FAILURE, HOTSPARE, PREDICTED FAILURE SOON. I > have tested in on my server and it works. I think it can be useful for > other implementations of soft RAID systems with hat swap support. I think it should be independent from RAID but having general enclosure support will be nice. Care to post the patches? Thanks. -- tejun -- 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
