Building as a kernel module (no kernel patching)

[0xbilko]

It would be nice to be able to build as a kernel module without having to patch the kernel. Is this realistic in the near future?

[edward6]

Currently not in plans.

[RJVB]

I agree that it would definitely make the filesystem a lot more accessible.

[edward-ibm]

I also agree

[RJVB]

What are the obstacles to turning ReiserFS4/5 into a module that's (largely) kernel version independent and can be built autonomously?

I noticed that a number of files of the kernel itself are patched, i.e. outside the RFS directory. I'm assuming the kernel ABI doesn't change because of this but I haven't looked if the changes only concern internal functions and/or structures or if they do change the APIs used by other filesystem modules like ZFS.

If the changes only concern internal functions and/or structures it should be possible to include those changes in the RFS module, as variants of the ones in the kernel, no? I noticed that ZFS uses this approach as a workaround for the kernel_fpu_begin/end functions that are no longer available to non-GPL'ed extensions.

[edward6]

The obstacle is VFS. It locks more than one page at once to speed up (on 5% :))) truncate operations for ext4. Such gang locks are incompatible with reiser4 transaction manager, so anyway you will need to patch the upstream kernel (currently, reiser4-patch suggests a new address_space operation to optionally prohibit the gang lock). Whereas, the interest is to build reiser4 without touching the upstream kernel, as I understand..

[RJVB]

Whereas, the interest is to build reiser4 without touching the upstream kernel, as I understand..

That would be ideal, yes. Though being able to build new reiser4 versions out-of-tree would already be an advantage, and I have a hunch that a properly-written patch that introduces a way to disable those gang locks should be easier to get accepted by upstream or at least distros.

This is well beyond my current zone of comfort, but are those locks used even if you don't have any ext4 filesystems mounted, does nothing else benefit from them, and could they be enabled only in the ext4 driver? I understand you can't simply deactivate by implementing your own version of the function(s) that use them?

[edward6]

Alas, this is the upper layer (VFS) who locks a number of pages at once. The mounted file system (regardless of its type) is not able to control the number of locked pages. Currently all the upstream file systems are happy with it (they don't have advanced transaction managers). I can prepare a separate patch for VFS to make the gang lock optional (it is rather simple), however it won't be accepted unless at least one upstream fs needs it. This is such a policy...

[RJVB]

And it doesn't look like VFS can be built as a module and this overridden and ReiserFS is slated for removal so making that require the anti-gang patch won't do much good either ;)

As I already indicated, applying a simple patch to make it possible to disable an incompatible feature in the running kernel is far less of a barrier than applying a complex patch set that may not even (yet) exist for the kernel you'd like to use or are using. Esp. if it's for testing and evaluation since you have no idea if reiser4 corresponds to your needs...

Plus, I find a 5% performance gain (for ext4) pretty respectable for a single optimisation "trick" (gang locks). I'm guessing that 5% was measured during synthetic testing so it may not show during daily use, but then again, it might show (stronger) under extreme load conditions.

[RJVB]

The mounted file system (regardless of its type) is not able to control the number of locked pages.

In case there's a distinction: it doesn't have to. All it would need to be able to do is say "don't lock more than a single page". Ext4 can apparently function without gang locks so it might be possible to implement this even if the page(s) that get locked are not filesystem-specific.