Re: [RFC] Disk shock protection (revisited)
> The general idea: A daemon running in user space monitors input data > from an accelerometer. When the daemon detects a critical condition, That sounds like a non starter. What if the box is busy, what if the daemon or something you touch needs memory and causes paging ? Given the accelerometer data should be very simple doesn't it actually make sense in this specific case to put the logic (not thresholds) in kernel space. > state. To this end, the kernel has to issue an idle immediate command > with unload feature and stop the block layer queue afterwards. Once the Yep. Pity the worst case completion time for an IDE I/O is 60 seconds or so. > 1. Who is to be in charge for the shock protection application? Should >userspace speak to libata / ide directly (through sysfs) and the low I think it has to be kernel side for speed, and because you will need to issue idle immediate while a command sequence is active which is *extremely* hairy as you have to recover from the mess and restart the relevant I/O. Plus you may need controller specific knowledge on issuing it (and changes to libata). > 2. Depending on the answer to the previous question, by what mechanism >should block layer and lld interact? Special requests, queue hooks or >something in some way similar to power management functions (once >suggested by James Bottomley)? Idle immediate seem to simply fit the queue model, it happens in *parallel* to I/O events and is special in all sorts of ways. > 3. What is the preferred way to pass device specific configuration >options to libata (preferrably at runtime, i.e., after module >loading)? sysfs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Disk shock protection (revisited)
The general idea: A daemon running in user space monitors input data from an accelerometer. When the daemon detects a critical condition, That sounds like a non starter. What if the box is busy, what if the daemon or something you touch needs memory and causes paging ? Given the accelerometer data should be very simple doesn't it actually make sense in this specific case to put the logic (not thresholds) in kernel space. state. To this end, the kernel has to issue an idle immediate command with unload feature and stop the block layer queue afterwards. Once the Yep. Pity the worst case completion time for an IDE I/O is 60 seconds or so. 1. Who is to be in charge for the shock protection application? Should userspace speak to libata / ide directly (through sysfs) and the low I think it has to be kernel side for speed, and because you will need to issue idle immediate while a command sequence is active which is *extremely* hairy as you have to recover from the mess and restart the relevant I/O. Plus you may need controller specific knowledge on issuing it (and changes to libata). 2. Depending on the answer to the previous question, by what mechanism should block layer and lld interact? Special requests, queue hooks or something in some way similar to power management functions (once suggested by James Bottomley)? Idle immediate seem to simply fit the queue model, it happens in *parallel* to I/O events and is special in all sorts of ways. 3. What is the preferred way to pass device specific configuration options to libata (preferrably at runtime, i.e., after module loading)? sysfs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Disk shock protection (revisited)
On Tue, 26 Feb 2008, Elias Oltmanns wrote: > > You don't want, for example, to swap out other apps, swap in the > > daemon, in order to handle a sudden acceleration. > > Quite. But with mlock this particular problem can be handled in user > space just fine. The only reason I can see right now for putting this And, as long as there is a way to also invoke it from within the kernel, we can call it from inside the kernel as well when there is a reason to make that function available. Full flexibility is easily attainable here and nothing we should bother about too much. > logic into the kernel as well is to keep the functionality around even Some hardware (Apple's?) has the entire APS logic in firmware (and AFAIK *also* export the accelerometer data for other uses). On those boxes, if you want to trust the firmware, you just ignore the accelerometer and hook to an interrupt. When you get the interrupt, you freeze the queue and unload heads. Adding that to work in-kernel would be trivial. Adding a suspend-time-only emergency HDAPS in-kernel monitor thread would also be doable, if we wanted to duplicate that for ThinkPads (I don't really think it is needed, but...). As long as queue freezing and the required unload immediate procedure can be called in at *any* time before the disk device, and its buses and controller are suspended, it would do to implement whatever we feel it is needed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Disk shock protection (revisited)
Jeff Garzik <[EMAIL PROTECTED]> wrote: > Elias Oltmanns wrote: >> The general idea: A daemon running in user space monitors input data >> from an accelerometer. When the daemon detects a critical condition, >> i.e., a sudden acceleration (for instance, laptop slides off the desk), >> it signals the kernel so the hard disk may be put into a (more) safe >> state. To this end, the kernel has to issue an idle immediate command >> with unload feature and stop the block layer queue afterwards. Once the >> daemon tells us that the imminent danger is over, the most important >> task for the kernel is to restart the block layer queue. See below for >> more details. > > Speaking specifically to that problem, it seems to me that you either > want an mlock'd daemon, or just simply to keep everything in the > kernel, for this specific solution. Yes, the daemon is mlock'd. > > You don't want, for example, to swap out other apps, swap in the > daemon, in order to handle a sudden acceleration. Quite. But with mlock this particular problem can be handled in user space just fine. The only reason I can see right now for putting this logic into the kernel as well is to keep the functionality around even after task freeze during suspend / resume. On the other hand, I don't know whether this is really worth the effort even though the time when the suspend operation is in progress can arguably be one of the most accident-prone moments (think of users packing their things in a hurry). Regards, Elias -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Disk shock protection (revisited)
Elias Oltmanns wrote: The general idea: A daemon running in user space monitors input data from an accelerometer. When the daemon detects a critical condition, i.e., a sudden acceleration (for instance, laptop slides off the desk), it signals the kernel so the hard disk may be put into a (more) safe state. To this end, the kernel has to issue an idle immediate command with unload feature and stop the block layer queue afterwards. Once the daemon tells us that the imminent danger is over, the most important task for the kernel is to restart the block layer queue. See below for more details. Speaking specifically to that problem, it seems to me that you either want an mlock'd daemon, or just simply to keep everything in the kernel, for this specific solution. You don't want, for example, to swap out other apps, swap in the daemon, in order to handle a sudden acceleration. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Disk shock protection (revisited)
Elias Oltmanns wrote: The general idea: A daemon running in user space monitors input data from an accelerometer. When the daemon detects a critical condition, i.e., a sudden acceleration (for instance, laptop slides off the desk), it signals the kernel so the hard disk may be put into a (more) safe state. To this end, the kernel has to issue an idle immediate command with unload feature and stop the block layer queue afterwards. Once the daemon tells us that the imminent danger is over, the most important task for the kernel is to restart the block layer queue. See below for more details. Speaking specifically to that problem, it seems to me that you either want an mlock'd daemon, or just simply to keep everything in the kernel, for this specific solution. You don't want, for example, to swap out other apps, swap in the daemon, in order to handle a sudden acceleration. Jeff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Disk shock protection (revisited)
Jeff Garzik [EMAIL PROTECTED] wrote: Elias Oltmanns wrote: The general idea: A daemon running in user space monitors input data from an accelerometer. When the daemon detects a critical condition, i.e., a sudden acceleration (for instance, laptop slides off the desk), it signals the kernel so the hard disk may be put into a (more) safe state. To this end, the kernel has to issue an idle immediate command with unload feature and stop the block layer queue afterwards. Once the daemon tells us that the imminent danger is over, the most important task for the kernel is to restart the block layer queue. See below for more details. Speaking specifically to that problem, it seems to me that you either want an mlock'd daemon, or just simply to keep everything in the kernel, for this specific solution. Yes, the daemon is mlock'd. You don't want, for example, to swap out other apps, swap in the daemon, in order to handle a sudden acceleration. Quite. But with mlock this particular problem can be handled in user space just fine. The only reason I can see right now for putting this logic into the kernel as well is to keep the functionality around even after task freeze during suspend / resume. On the other hand, I don't know whether this is really worth the effort even though the time when the suspend operation is in progress can arguably be one of the most accident-prone moments (think of users packing their things in a hurry). Regards, Elias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Disk shock protection (revisited)
On Tue, 26 Feb 2008, Elias Oltmanns wrote: You don't want, for example, to swap out other apps, swap in the daemon, in order to handle a sudden acceleration. Quite. But with mlock this particular problem can be handled in user space just fine. The only reason I can see right now for putting this And, as long as there is a way to also invoke it from within the kernel, we can call it from inside the kernel as well when there is a reason to make that function available. Full flexibility is easily attainable here and nothing we should bother about too much. logic into the kernel as well is to keep the functionality around even Some hardware (Apple's?) has the entire APS logic in firmware (and AFAIK *also* export the accelerometer data for other uses). On those boxes, if you want to trust the firmware, you just ignore the accelerometer and hook to an interrupt. When you get the interrupt, you freeze the queue and unload heads. Adding that to work in-kernel would be trivial. Adding a suspend-time-only emergency HDAPS in-kernel monitor thread would also be doable, if we wanted to duplicate that for ThinkPads (I don't really think it is needed, but...). As long as queue freezing and the required unload immediate procedure can be called in at *any* time before the disk device, and its buses and controller are suspended, it would do to implement whatever we feel it is needed. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
