[Btrfs-devel] BTRFS and old kernels.
Bron Gondwana
brong at fastmail.fm
Sat Apr 5 18:31:45 PDT 2008
On Sun, Apr 06, 2008 at 10:57:12AM +1000, Bron Gondwana wrote:
> On Sat, Apr 05, 2008 at 08:13:47PM +0100, Miguel Sousa Filipe wrote:
> > My question is, is there sill interestest in having btrfs compatible
> > with older kernels (like, 2.6.20 or 2.6.18)?
> > I'll post (or repost) patches that I need for btrfs-unstable to
> > build/work on this ppc system of mine.
>
> It sort of depends who you ask. Personally, I see value in being
> compatible with as wide range of kernels as possible in a development
> filesystem that you want people to be testing. But then I'm not
> doing any btrfs development, so I don't count for much.
I guess I should justify this a bit....
ASSUME: I have a bunch of production Debian Etch machines running
the latest Debian Etch production kernel (2.6.18-6-amd64
sounds like a convincing sort of version number) and I want
to benchmark/test btrfs in my environment.
CASE 1: I can upgrade the kernel on this system to 2.6.24+ and make
sure all my hardware still works as expected, upgrade my
udev/hal/whatever to be compatible. Possibly backport some
userland tools that use new interfaces now... sounds like
a whole pile of fun^H^H^Hwork.
CASE 2: I can build a standalone btrfs module against my current
kernel and test, having changed nothing but the filesystem.
I know which one I would trust to give me a better idea of how
stable/performant[1] btrfs is on my platform.
(this all assuming that there aren't architectural changes in the
intervening layers that make btrfs not work properly on the older
kernels, but ext3/xfs/jfs/reiserfs/name-your-poison seem to have
all remained stable right through those transitions[2].)
Bron.
[1] screw you http://boulter.com/blog/2004/08/19/performant-is-not-a-word/
and friends...
[2] ok, there have been some exceptions to that, for example:
http://oss.sgi.com/projects/xfs/faq.html#dir2
More information about the Btrfs-devel
mailing list