LP# 440522: FSCACHE modules not compiled in
lists at nerdbynature.de
Wed Mar 10 21:56:20 UTC 2010
On Wed, 10 Mar 2010 at 10:52, Tim Gardner wrote:
> > As stated in the bugreport this flag has been removed upstream now, for
> > 2.6.34. However, as pointed out in the report and in  too, the
> > EXPERIMENTAL flag is not considered useful any more by many upstream
> > developers.
> Activity in the 2.6.34 kernel isn't relevant to the code base we have in
True. My point however was, that the EXPERIMENTAL flag "more or less means
nothing". I understand that this rationale is not something new and not
bound to 2.6.34 (where, in consequence, the flag has been removed) but can
be applied to earlier kernel versions as well. It was only Leann's comment
in #440522 which made me approach upstream to remove the flag. However, I
still don't understand the real reasoning here, as Ubuntu clearly has
other EXPERIMENTAL features enabled (not just related to fscache).
Also, I still don't understand why 1) CONFIG_FSCACHE is enabled and 2)
we're shipping the cachefilesd package, as both are pretty much unusable
without proper filesystem support.
> At this late stage in the development process (kernel freeze was effectively
> yesterday) it just ain't gonna happen.
Hm, indeed, I won't argue with that.
> We _might_ consider an SRU after Lucid
> has been released, but only if there is compelling evidence that NFS caching
> does not affect stability (i.e., no regressions),
Sounds good. Yes, I noticed the "might" :-)
> and that it provides a real benefit.
There are ineed noticable speedup when mounting with -o fsc, but I haven't
done any benchmarks (yet).
Thanks for your time thinking about this, Tim. With the kernel freeze
happening and Lucid almost out of the door, I can imagine that your busy
with lots of other things. Your comments on this are highly apreaciated
and I look forward to an Ubuntu release with *_FSCACHE enabled.
BOFH excuse #331:
those damn raccoons!
More information about the kernel-team