NeilBrown <neilb@xxxxxxxxxxxxxxx> wrote: > > Every interesting md event (device failure, rebuild, add,remove etc) gets treated > as an 'urgent data' on /proc/mdstat and cause select to return if waiting for exceptions, > and poll to return if waiting PRIority data. > > To collect an event, the program must re-read /proc/mdstat from start to finish, > and then must select/poll on the file descriptor (or close it). > > Events aren't returned as a list of individual events, only as a notification > that something might have happened, and reading /proc/mdstat should show what > it was. > > If a program opens /proc/mdstat with O_RDWR it signals that it intends > to handle events. In some cases the md driver might want to wait for > an event to be handled before deciding what to do next. For example > when the last path of a multipath fails, the md driver could either > fail all requests, or could wait for a working path to be provided. > It can do this by waiting for the failure event to be handled, and > then making the decission. A program that is handling events should > read /proc/mdstat to determine new state, and then handle any events > before either calling select/poll. By doing this, or by closing the > file, the program indicates that it has done all that it plans to do > about the event. Christoph points out that this is fairly wild procfs abuse. We want to be moving away from that sort of thing, not adding to it. Is it possible to use rml's new event stuff from rc1-mm3's kernel-sysfs-events-layer.patch? Or a bare netlink interface? Or raidfs? - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
