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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |