Kernel modules not compiled (Stats, NFS, AFS, etc)

Bug #440522 reported by Wido den Hollander
This bug affects 15 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Tim Gardner
Nominated for Lucid by arielUBA
Fix Released
Tim Gardner

Bug Description

Binary package hint: cachefilesd

I just upgraded my desktop to Ubuntu 9.10 because i wanted to test the cachefilesd package for caching NFS.

My /home directory is running over NFS, so i hoped cachefilesd would give me some performance.

After installing and configuring i saw that there was no caching started in /var/cache/fscache.

Some searching on Google brought me to:

It seems that the kernel modules are not compiled in the kernel:

root@wido-desktop:~# cat /boot/config-2.6.31-11-generic |grep FSCACHE
root@wido-desktop:~# apt-cache search cachefiles
cachefilesd - support fscache on already mounted filesystem

root@wido-desktop:~# uname -a
Linux wido-desktop 2.6.31-11-generic #36-Ubuntu SMP Fri Sep 25 06:37:23 UTC 2009 x86_64 GNU/Linux

Is there a possibility these kernel modules are going to be compiled into the kernel? If not, can they be delivered in a seperate package?

Tags: kconfig
Jorge Castro (jorge)
Changed in cachefilesd (Ubuntu):
status: New → Confirmed
Revision history for this message
Jorge Castro (jorge) wrote :

I don't know if this is related but I thought I would add more information. I am pretty sure cachefs is working for me:

jorge@bojack:~$ time cp /home/jorge/Backup/ISO/ubuntu/lucid-alternate-amd64.iso .
real 2m24.703s
user 0m0.000s
sys 0m1.260s
jorge@bojack:~$ cd Desktop/
jorge@bojack:~/Desktop$ time cp /home/jorge/Backup/ISO/ubuntu/lucid-alternate-amd64.iso .

real 0m0.796s
user 0m0.000s
sys 0m0.770s

however there doesn't appear to be anything in the cache directory which is specified in /var/cache/fscache:

root@bojack:~/Desktop# du -h /var/cache/fscache/
4.0K /var/cache/fscache/graveyard
4.0K /var/cache/fscache/cache
12K /var/cache/fscache/

Revision history for this message
Ka-Hing Cheung (kahing) wrote :

are you sure this is going through the on disk cache and not the in memory cache?

Revision history for this message
Christian Kujau (christiank) wrote :

@Jorge: no, this has nothing to do with cachefilesd, this is your "normal" filesystem cache.

The issue Wido raised is that the *_FSCACHE modules are not compiled into the kernel and hence cachefilesd is not working.

Revision history for this message
Jorge Castro (jorge) wrote :

Indeed you are correct. Someone posted about this on the kernel list:

and it looks like it was not reviewed during the UDS kernel config review:

I am unsure if the module is still considered experimental in the upstream .32 kernel, but grepping my config in Lucid shows it as disabled like Wido's config.

Leann maybe you can point us to the right person on the kernel team?

Changed in cachefilesd (Ubuntu):
assignee: nobody → Leann Ogasawara (leannogasawara)
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

First, I'm reassigning this to the linux kernel package.

Next, I've examined the Lucid kernel configs and this is still noted as EXPERIMENTAL. As Tim noted in the kernel team mailing list, we do not typically enable experimental config options. Setting this to wishlist for now. Will try to bring this up for discussion with the team. Thanks.

        bool "Provide NFS client caching support (EXPERIMENTAL)"
        depends on EXPERIMENTAL
        depends on NFS_FS=m && FSCACHE || NFS_FS=y && FSCACHE=y
          Say Y here if you want NFS data to be cached locally on disc through
          the general filesystem cache manager

affects: cachefilesd (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
importance: Undecided → Wishlist
status: Confirmed → Triaged
Revision history for this message
Wido den Hollander (wido) wrote :

Ah, sounds great!

And since i am not that into compilen modules myself, how could i compile the .ko files myself so i can load them manually?

I should be able to build these files against the source without rebuilding my whole kernel, right?

Changed in linux (Ubuntu):
assignee: Leann Ogasawara (leannogasawara) → nobody
tags: added: kconfig
Revision history for this message
Christian Kujau (christiank) wrote :

@Leann: Perhaps it's too late now, I should've double checked the moment you were replying: you're saying that the *_FSCACHE modules cannot be enabled in an Ubuntu kernel, because they depend on EXPERIMENTAL. While I'm currently trying to convince[0] upstream to remove the EXPERIMENTAL flag from NFS_FSCACHE, I just noticed that both CONFIG_FSCACHE and CONFIG_CACHEFILES is already enabled in Karmic - which are both marked EXPERIMENTAL (since CACHEFILES depends on FSCACHE).

So, I just have to ask: how comes?

From looking at a Karmic config (2.6.31-20-server) I can see that there are other options, which are enabled as well, despite the fact that they depend on EXPERIMENTAL.

Also, Ubuntu is currently shipping the userspace cachefilesd daemon - which is unusable, without the proper kernel support.

So, if anyone from the kernel team reads this - please reconsider and enable the missing *_FSCACHE options.



Changed in linux (Ubuntu):
assignee: nobody → Ubuntu Kernel Team (ubuntu-kernel-team)
Revision history for this message
Gionn (giovanni.toraldo) wrote :

+1 (fscache works flawlessy in Debian Squeeze)

Pete Graner (pgraner)
Changed in linux (Ubuntu):
status: Triaged → Won't Fix
Revision history for this message
Christian Kujau (christiank) wrote :

FWIW, the experimemental tag has been removed in mainline:

@Pete: please elaborate if you're changing bugs to WONTFIX.

Changed in linux (Ubuntu):
status: Won't Fix → Confirmed
Revision history for this message
Wido den Hollander (wido) wrote :

In the latest Lucid kernel these modules aren't compiled as we speak, is there any change that they will make it into the final release?

Revision history for this message
Christian Kujau (christiank) wrote :

@Leann: can you change the importance from wishlist back to something more serious? Without the *_FSCACHE options, the cachefilesd package is pretty much useless :-\

Changed in linux (Ubuntu Maverick):
milestone: none → maverick-alpha-2
status: Confirmed → Triaged
Tim Gardner (timg-tpi)
Changed in linux (Ubuntu Maverick):
assignee: Ubuntu Kernel Team (ubuntu-kernel-team) → Tim Gardner (timg-tpi)
importance: Wishlist → Low
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 2.6.35-4.5

linux (2.6.35-4.5) maverick; urgency=low

  [ Leann Ogasawara ]

  * Revert "[Upstream] (evdev) Use driver hint to compute the evdev buffer
    size (rev2)"
  * Revert "[Upstream] (evdev) Convert to dynamic event buffer (rev4)"
  * Revert "[Upstream] (evdev) Use multi-reader buffer to save space
  * Revert "SAUCE: drivers: Remove some duplicate device entries in various
  * [Upstream] USB: option: Remove duplicate AMOI_VENDOR_ID
  * [Upstream] Revert "USB: Adding support for HTC Smartphones to ipaq"
  * [Upstream] p54usb: Comment out duplicate Medion MD40900 device id

  [ Tim Gardner ]

    - LP: #440522
    - LP: #440522
 -- Leann Ogasawara <email address hidden> Wed, 16 Jun 2010 08:43:07 -0700

Changed in linux (Ubuntu Maverick):
status: In Progress → Fix Released
Revision history for this message
arielUBA (arielandres-hotmail) wrote :

Since Lucid is a LTS version, please consider backporting the fix.

Revision history for this message
Wido den Hollander (wido) wrote :

I agree, this would really be a nice feature for Lucid. Can a backport be considered?

Revision history for this message
lorello (lorello) wrote :

Oh yes, please backport it, this is a too interesting feature to leave it away from the recent LTS Release. Thanks!

Revision history for this message
Patrick Donnelly (batrick) wrote :

Backport would be awesome.

Revision history for this message
Tim Gardner (timg-tpi) wrote :

You can always use the LTS backport kernel from Choose your favorite meta package from linux-meta-lts-backport-maverick.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.