Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2005-08-26 11:39:26 -0400 \ Poyner, Brandon: > > well, if someone tries to write to the secondary, > > he gets an io error, and the message is "no io allowed". > > if someone tries to read from the secondary, > > he gets an io error, and the message is "no io allowed". > > where is the problem? > > The problem is the assumption that I know what was going on. It's one > thing if I were trying to mount the device, I could directly see the > relation between my commands and the error. It's another matter when > that error shows up over night for no obvious reason. Normally I'd be > left wondering 1) what tried to access the device 2) was the IO request > read or write 3) and is this a serious error? I don't think the drbd > module would have direct access to #1 (yes/no?). It should know the > answer to #2, and #3 depends on #1 and #2. If I only had access to #2 I > could make a more informed decision. #1: we could log the current comm and pid, if that helps. #2: see below. > > I can make the message read > > "neither read nor write requests allowed while in secondary mode" > > > > if you are worried about failing writes, > > watch out for kernel messages like > > "lost page write due to I/O error on <devicename>" > > and similar... > > Ok, that's helpful, but I stand by my assertion that clarifying the IO > type would help me figure out the gravity of the situation. as a secondary cannot be opened with write intent, write requests cannot be submitted. -- : Lars Ellenberg Tel +43-1-8178292-0 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schoenbrunner Str. 244, A-1120 Vienna/Europe http://www.linbit.com : __ please use the "List-Reply" function of your email client.