Thread (4 messages) 4 messages, 2 authors, 2004-09-03

Re: [PATCH md 1 of 2] Add interface to md driver for userspace monitoring of events.

From: Andrew Morton <hidden>
Date: 2004-09-03 10:19:20

NeilBrown [off-list ref] 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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help