LP# 440522: FSCACHE modules not compiled in

[Christian Kujau]

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 [0] 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
> 2.6.32.

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.

Christian.
-- 
BOFH excuse #331:

those damn raccoons!