Messages in this thread |  | | Date | Sun, 17 Jul 2005 21:45:58 +0200 | From | bert hubert <> | Subject | Re: [PATCH] Re: relayfs documentation sucks? |
| |
On Sun, Jul 17, 2005 at 10:43:40AM -0500, Tom Zanussi wrote:
> It is racey - in this mode, there's nothing to keep the kernel from > writing as much as it wants before the user side has a chance to read > any of it. The only way this can be used safely is to make sure the > kernel side isn't writing anything when the client is reading. This > would be typical of a flight-recording usage i.e. kernel writes a > bunch of data continuously, then stops and allows the client to read > whatever's in there.
Or by numbering entries written out, when in flight-recording mode you wouldn't want to block the kernel.
> > In fact, it appears this might even happen in non-overwrite mode. > > It shouldn't ever be able to happen in non-overwrite mode - if it > did, it would be a bug. Can you be more specific as to how you see > this happening in this mode?
Yeah - you're right. The misunderstanding is because in both cases (overwrite and non-overwrite) data is lost, except that in one case you lose old data, and in the other new data.
It might be a good idea to document this as well.
Btw, I've already uncovered interesting things using relayfs, but I still don't see the case for having it merged :-)
Thanks for your answers, I think I get it all now.
-- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |