FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 03-08-2010, 08:44 PM
Christian Kujau
 
Default LP# 440522: FSCACHE modules not compiled in

Hi,

Lucid LTS is probably almost ready and maybe gone to feature-freeze
already and I worry about a pet-peeve of mine, #LP 440522. The bugreport
is reassigned between teams, even changed to WONTFIX some time ago but
there's no consensus in sight. The summary so far:

1) CONFIG_FSCACHE is already enabled in Karmic, but for this to work
(and the "cachefilesd" package to be usable at all), the according
NFS_FSCACHE resp. AFS_FSCACHE have to be enabled.

2) There was an argument that Ubuntu typically doesn't enable
EXPERIMENTAL modules - this has been resolved, AFAICT.

What's missing here? Should I generate a patch against the "linux"
package in Ubuntu? (That would qualify as an non-maintainer-upload, if
something like this exists in Ubuntu). I don't think enabling these
modules will be a real burden for the Ubuntu team, as bugs will have to be
addressed upstream as well. Also, it seems only logical to me to enable
the *FS_FSCACHE modules, otherwise the already enabled FSCACHE option
would be useless (as it is now).

Thank you for your comments,
Christian.
--
BOFH excuse #120:

we just switched to FDDI.

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 03-09-2010, 12:56 PM
Tim Gardner
 
Default LP# 440522: FSCACHE modules not compiled in

On 03/08/2010 02:44 PM, Christian Kujau wrote:
> Hi,
>
> Lucid LTS is probably almost ready and maybe gone to feature-freeze
> already and I worry about a pet-peeve of mine, #LP 440522. The bugreport
> is reassigned between teams, even changed to WONTFIX some time ago but
> there's no consensus in sight. The summary so far:
>
> 1) CONFIG_FSCACHE is already enabled in Karmic, but for this to work
> (and the "cachefilesd" package to be usable at all), the according
> NFS_FSCACHE resp. AFS_FSCACHE have to be enabled.
>
> 2) There was an argument that Ubuntu typically doesn't enable
> EXPERIMENTAL modules - this has been resolved, AFAICT.
>
> What's missing here? Should I generate a patch against the "linux"
> package in Ubuntu? (That would qualify as an non-maintainer-upload, if
> something like this exists in Ubuntu). I don't think enabling these
> modules will be a real burden for the Ubuntu team, as bugs will have to be
> addressed upstream as well. Also, it seems only logical to me to enable
> the *FS_FSCACHE modules, otherwise the already enabled FSCACHE option
> would be useless (as it is now).
>
> Thank you for your comments,
> Christian.

The issue with NFS_FSCACHE in particular is that upstream support
appears to be lukewarm, e.g., neither fscache.c or fscache-index.c has
been touched since April 2009, yet the feature is still marked
EXPERIMENTAL. Furthermore, NFS_FSCACHE cannot be built as a module,
i.e., enabling this feature is going to affect the base NFS
implementation. Until this situation changes, I'm not going into a long
term release with an experimental feature in the mainline NFS path.

rtg
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 03-09-2010, 07:14 PM
Christian Kujau
 
Default LP# 440522: FSCACHE modules not compiled in

On Tue, 9 Mar 2010 at 06:56, Tim Gardner wrote:
> The issue with NFS_FSCACHE in particular is that upstream support appears to
> be lukewarm, e.g., neither fscache.c or fscache-index.c has been touched since
> April 2009,

According to git-log, fs/nfs/fscache.c, has been touched in Sep 2009, Nov
2009 and now in March again. fs/fscache has been touched in Nov 2009, the
same goes for fs/cachefiles.

> yet the feature is still marked EXPERIMENTAL.

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.

Furthermore, Ubuntu has enabled other EXPERIMENTAL features (e.g.
CONFIG_FSCACHE, which only recently had its EXPERIMENTAL flag removed).

> Furthermore, NFS_FSCACHE cannot be built as a module

Indeed, the bug description should be changed :-)

> i.e., enabling this feature is going to affect the base NFS implementation.
> Until this situation changes, I'm not going into a long term release with
> an experimental feature in the mainline NFS path.

OpenSuse does it (since at least May 2005), Fedora does it too[1]. Again,
I agree with Arjan[0] here: it's not EXPERIMENTAL just because someone
tagged it so. If not enabled, nothing changes from a user's perspective.
If bugs are found (with caching enabled or not), they're likely NOT to
occur only on Ubuntu machines but will have to be addressed upstream.

Please reconsider.

Thanks,
Christian.

[0] http://marc.info/?l=linux-nfs&m=126684776217594&w=2
[1] http://lwn.net/Articles/160122/
--
BOFH excuse #68:

only available on a need to know basis

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 03-10-2010, 04:52 PM
Tim Gardner
 
Default LP# 440522: FSCACHE modules not compiled in

On 03/09/2010 01:14 PM, Christian Kujau wrote:
> On Tue, 9 Mar 2010 at 06:56, Tim Gardner wrote:
>> The issue with NFS_FSCACHE in particular is that upstream support appears to
>> be lukewarm, e.g., neither fscache.c or fscache-index.c has been touched since
>> April 2009,
>
> According to git-log, fs/nfs/fscache.c, has been touched in Sep 2009, Nov
> 2009 and now in March again. fs/fscache has been touched in Nov 2009, the
> same goes for fs/cachefiles.
>

You are correct. Not sure how I missed that.

>> yet the feature is still marked EXPERIMENTAL.
>
> 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.

> Furthermore, Ubuntu has enabled other EXPERIMENTAL features (e.g.
> CONFIG_FSCACHE, which only recently had its EXPERIMENTAL flag removed).
>
>> Furthermore, NFS_FSCACHE cannot be built as a module
>
> Indeed, the bug description should be changed :-)
>
>> i.e., enabling this feature is going to affect the base NFS implementation.
>> Until this situation changes, I'm not going into a long term release with
>> an experimental feature in the mainline NFS path.
>
> OpenSuse does it (since at least May 2005), Fedora does it too[1]. Again,
> I agree with Arjan[0] here: it's not EXPERIMENTAL just because someone
> tagged it so. If not enabled, nothing changes from a user's perspective.
> If bugs are found (with caching enabled or not), they're likely NOT to
> occur only on Ubuntu machines but will have to be addressed upstream.
>
> Please reconsider.
>
> Thanks,
> Christian.
>
> [0] http://marc.info/?l=linux-nfs&m=126684776217594&w=2
> [1] http://lwn.net/Articles/160122/

At this late stage in the development process (kernel freeze was
effectively yesterday) it just ain't gonna happen. 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), and that it provides a real benefit.

Your best bet is to ensure this feature is enabled for L+1.

rtg
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 03-10-2010, 08:56 PM
Christian Kujau
 
Default LP# 440522: FSCACHE modules not compiled in

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!

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 03:21 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org