How 'lossy' is relayfs?
With the right buffer sizes, not
at all - any data loss with properly-sized buffers would be considered a
bug. But before you come to the conclusion that relayfs is losing
data, please try the following:
Add a 'lost-events' counter to your kernel code. e.g.
static int subbuf_start_handler(struct rchan_buf *buf,
void *subbuf,
void *prev_subbuf,
unsigned int prev_padding)
{
if (relay_buf_full(buf)) {
dropped++;
return 0;
}
return 1;
}
Define the callback like this:
static struct rchan_callbacks relayfs_callbacks =
{
.subbuf_start = subbuf_start_handler,
};
And pass it to relay open:
chan = relay_open("cpu", dir, subbuf_size,
n_subbufs, &relayfs_callbacks);
Then either printk the dropped value at the end of the run, or look at
the relay-apps examples for an example of how to export the value using a non-relay file
(like a proc file but in relayfs).
This assumes you're using no-overwrite mode. If you're using overwrite mode, then by definition the buffer never becomes full and you're overwriting old data with new when the buffer wraps around.
If this kernel dropped count is > 0, you know you're losing events because the reader can't or isn't keeping up, and either the reader needs to be fixed, or the buffer sizes need to be increased.
If you're seeing 0 drops in the kernel and you're still missing data, then either the reader isn't reading the ready data correctly, or it's not counting the data correctly. If this is the case, please try to verify that your counting mechanism is correct - in almost every case of lost data reported so far, this was the problem.
If you still have kernel data losses even with large buffer sizes, are you trying to log so much data that the daemon can't reasonably keep up? Is writing it to disk the bottleneck e.g. if you try commenting out the actual write()s in the daemon, does the problem still exist?
If you're sure that none of the above are the source of the problem and suspect it might be the relayfs read() implementation (if you're using that) or something else in relayfs, please try to send a reproducible test case - it's very time-consuming and difficult to try to track down reports of data loss without this or something concrete to go on. Thanks...
What's the difference between the "new" relayfs and the "old" relayfs?
[Update: relayfs is now included in the mainline kernel.]
The "old" relayfs was the first version of relayfs, and while it was quite functional and did everything it advertised, it began to suffer over time from 'creeping featuritis', and needed to be pared down and simplified in order to be considered for inclusion in the mainline kernel. The result of several rounds of modification after input from the kernel community is the "new" relayfs, which is the version now included in the -mm tree.
The "old" version is still bugfix-supported for current users, but is considered obsolete, and shouldn't be used in new projects, at least those projects that aren't meant to be strictly out-of-tree.
Is there a relayfs version for non-mm kernels?
[Update: relayfs is now included in the mainline kernel, and is no longer in the -mm kernel]
No, but it's not hard to move it to another kernel. Just copy fs/relayfs/* and include/linux/relayfs_fs.h to the new kernel, and copy the relayfs config entry from fs/Kconfig and the one line mentioning relayfs in fs/Makefile to the new kernel, configure and compile, and you should be up and running.
Is there a relayfs version for 2.4 kernels?
Yes. Thanks to Hareesh Nagarajan, there is - see the project files page.