11–20 of 24 posts
If a directory has a time-to-live of 8 hours, then any files or subdirectories inside the directory will be deleted 8 hours after their last modification.
That way the applications that work on these files don't need to be setting special attributes on every file.
This seems a little roundabout. Why is this preferable over using `inotify(7)`? That's an existing system which can notify your userspace driver program about any time `setxattr(2)` is called. I get that it's fun to experiment with BPF, but it's also useful to see how many tools already exist. BPF is powerful, yes - maybe too powerful, and it's often not the best tool for the job.
Here you probably want fanotify, not inotify. The later would require setting up a lot of inotify entries, recursing through the filesystem. https://man7.org/linux/man-pages/man7/fanotify.7.html I think fanotify does xattrs, but I haven't tested.
BPF --> Berkley Packet Filter Maybe this comment will save you a google. But probably not. https://en.wikipedia.org/wiki/Berkeley_Packet_Filter
Funnily enough, although this calls it BPF, the technology in the article refers to eBPF ( https://en.wikipedia.org/wiki/EBPF ): https://docs.kernel.org/bpf/index.html -- which, although rooted in the OG BPF, is only distantly related.
> BPF stands for Berkeley Packet Filter, an obscure technology first developed in 1992 that improved the performance of packet capture tools. In 2013, Alexei Starovoitov proposed a major rewrite of BPF, which was further developed by Alexei and Daniel Borkmann and included in the Linux kernel in 2014. This turned BPF into a general-purpose execution engine that can be used for a variety of things, including the creation of advanced performance analysis tools.
> [...]
> Extended BPF is often abbreviated as eBPF, but the official abbreviation is still BPF, without the “e,” so throughout this book I use BPF to refer to extended BPF. The kernel contains only one execution engine, BPF (extended BPF), which runs both extended BPF and “classic” BPF programs.¹
> ¹ Classic BPF programs (which refers to the original BPF) are automatically migrated to the extended BPF engine by the kernel for execution. Classic BPF is also not being developed further.
Earlier quoted context omitted.
Here you probably want fanotify, not inotify. The later would require setting up a lot of inotify entries, recursing through the filesystem. https://man7.org/linux/man-pages/man7/fanotify.7.html I think fanotify does xattrs, but I haven't tested.
Exactly this. I should have mentioned it in the post. Might amend it. Would be interesting to compare the chances of race conditions with inotify vs BPF for this contrived use-case.
Doesn’t take away from the original point that bpf is cool.
Quite clearly from the "solution looking for a problem" dept. If one ever happenes to casually find 'several petabytes of old logs that were not deleted', whoever's in charge should consider having several people fired over that.
Author here! As some comments mention, there are other approaches that could make more sense. The aim of this proof-of-concept was to showcase how BPF enables the kernel to be programmable. Many behaviours can be retrofitted without having to submit changes upstream. In some cases the overhead may be lower than using other methods (due to avoiding context switches, etc). Even if you decide that the changes can be use…
For example, consider CreateProcess vs fork/exec: at the first glance, the first one is the most obvious and sensible, you want a program launched, you point the OS at the executable and say "execute this". The second API instead makes you to make a perfect copy of the currently executing process, then you tell the OS to completely scrape and discard its state and launch another executable file inside it. Literally no other object in the system works this way (i.e. to create a new X, you must copy an already existing X first, then modify with the copy).
But then consider that you would also like to configure the environment of the newly launched program before it actually launches, and that's when CreateProcess API starts to lose its simplicity: you have to pass all imaginable (and some unimaginable) kinds of configuration, and the API has to be extensible and future-proof, too! Just look at what kind of silliness goes into thread-attribute lists [0]. But with fork/exec, you simply run the normal, user-space code that configures the current process whatever way it pleases, then swaps the executable, done — and you can't do that with CreateProcess, you can't just ask the kernel to run some arbitrary user-provided code in the kernel context... unless it's not entirely arbitrary: enter eBPF.
[0] https://learn.microsoft.com/en-us/windows/win32/api/processt...
Earlier quoted context omitted.
Exactly this. I should have mentioned it in the post. Might amend it. Would be interesting to compare the chances of race conditions with inotify vs BPF for this contrived use-case.
Just curious why you wouldn’t amend it? Doesn’t take away from the original point that bpf is cool.
Quite clearly from the "solution looking for a problem" dept. If one ever happenes to casually find 'several petabytes of old logs that were not deleted', whoever's in charge should consider having several people fired over that.
You'd fire people for leaving around some log files?
Quite clearly from the "solution looking for a problem" dept. If one ever happenes to casually find 'several petabytes of old logs that were not deleted', whoever's in charge should consider having several people fired over that.
You'd fire people for leaving around some log files?
Serious business these things.
BPF --> Berkley Packet Filter Maybe this comment will save you a google. But probably not. https://en.wikipedia.org/wiki/Berkeley_Packet_Filter
Funnily enough, although this calls it BPF, the technology in the article refers to eBPF ( https://en.wikipedia.org/wiki/EBPF ): https://docs.kernel.org/bpf/index.html -- which, although rooted in the OG BPF, is only distantly related.