-
Notifications
You must be signed in to change notification settings - Fork 875
Changes related to new option added: --pipeoutput. #458
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Could you please explain what advantage this change provides compared to the existing |
@infrastation Hi, thanks for looking into this. The difference becomes apparent if you're using tcpdump for a long running high-rate capture. Piping output to gzip and saving to a file works but the file will keep growing indefinitely. You really want to keep writing multiple files and compressing them on the fly, to save the disk bandwidth. |
Now it is easier to understand, thank you. |
307efd9
to
99c91c3
Compare
@infrastation Hi Denis, have you had a chance to review this patch? Can we pull it or discuss why it's a bad idea? |
OK, I'm not sure why Travis clang check failed; I tried clang and it all worked. Any ideas? I'm using a different version of clang though (3.5.0) |
@infrastation fixed the bug that failed tests. Ready for a pull! |
Folks, can you please pull or give a reason not to? |
Everybody has been plainly backlogged with other work, please excuse us. Could you rebase on the current master branch and make it one clean commit to make it easier to review? |
Just want to check if this has been already merged. I was looking for exactly this feature to reduce the amount of disk I/O. |
This is an important feature for enterprise users. How can I help to merge this ASAP? |
@yp-isi in the meantime I think this could be a hacky workaround. Let me know what you think: What I think is problematic with my approach is that it's not clear:
So having an option that's proposed in this PR would be helpful. |
It works on some level, but if your goal is to be able to process splits individually, this is not going to work, not only do you need to split before the compression, but also:
Since the patch didn't find any traction here, we've created our own package to do this build around |
@yp-isi thanks. Would be also great if that was on e.g. GitHub with a README.md etc. |
@yp-isi Also since I don't find any other channel, I cannot compile your source (v0.1 nor v0.4) on Ubuntu 19.04. Libtrace was installed as in https://github.com/LibtraceTeam/libtrace/wiki/Installing-Libtrace and
|
@yp-isi I've created a min mtracecap CMake project (and fixed the issue above) here https://github.com/jmakov/mtracecap. Please copy it and publish (so I can fork from you) on e.g. Github so we can send pull requests to you. Let me know when you do so I can delete my Github mtracecap repository. |
do you have time/energy to rebase this? |
This is a patch implementing a newoption --pipeoutput
This option allows you to pipe captured stream and process it in-line, before saving it to a file.
A use case is saving disk bandwidth using a fast compressor e.g. snappy before saving.
Compare this with postrotate:
-z snzip:
##--pipeoutput
This is compelling since it saves one full read/one full write, while potentially utilizing other cores