I spent last week at the LinuxTag 2009 conference in Berlin. There I
unexpectedly met up with Lino Sanfilippo. Together we had a great
hacking session and were able to tackle a lot of DazukoFS issues. Some
of these include:
- Finally handling mmap() cleanly! PROT_WRITE is now correctly
unsupported so applications can safely fallback to regular file IO.
- Fixed a bug when multiple stackable filesystems are stacked onto
each other. All other stackable filesystems also have this bug at
the moment. I plan to submit a patch to mainline to fix ecryptfs as
- As suggested on LKML, we are now using the pid framework. This
should allow DazukoFS to work correctly with pid namespaces. (If you
use pid namespaces, I would greatly appreciate testing feedback.)
- Reading directories is now handled correctly. Until now you could
sometimes see "invalid argument" error messages when using the grep
tool. ecryptfs also has this problem. I plan to submit a patch to
mainline to fix ecryptfs as well.
- libdazukofs will now allow dazukofs_open() to be successful for a
read-only /dev/dazukofs.ctrl if the group already exists. This makes
it possible to run full on-access scanners _without_ever_ starting
the application as root.
Version 3.1.0-rc1 has been updated to support Linux 2.6.30. Right now
there are no other patches included to support other versions.
I had a blast at LinuxTag. Many thanks go out to Lino Sanfilippo for
the many great discussions, new ideas, and lots of hacking fun.
On 2009-06-28, John Ogness <[hidden email]> wrote:
> - As suggested on LKML, we are now using the pid framework. This
> should allow DazukoFS to work correctly with pid namespaces. (If
> you use pid namespaces, I would greatly appreciate testing
I just realized that the pid namespace implementation for 3.1.0-rc1 is
not complete. If registered applications are not part of the global
pid namespace, the pid value they get is garbage for anonymous
processes outside their pid namespace.
What would be the correct solution here? We could either return an
invalid pid value (such as 0) or drop the event (so that the
registered application never sees it).
I prefer returning a pid value of 0. This gives the application the
chance to decide if it wants to process the event or not. By seeing a
pid value of 0, the applications knows that it is dealing with an
event for a process outside of its pid namespace.