Backport btrfs from upstream git head into Karmic's kernel

Bug #481404 reported by John Dong on 2009-11-12
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Undecided
Unassigned

Bug Description

The btrfs in 2.6.31 has some blemishes which have been addressed in Chris Mason's git (http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git) pending merge into 2.6.32

Namely:

* ENOSPC panics
* Incorrect metadata reservation leads to disk full at somewhere around 70% of expected disk capacity
* Huge performance increases due to smarter caching (for bootup, around a doubled speed)
* Misc panics and oops

The regression potential is minor: These are primarily bugfix releases backward and forward compatible for existing btrfs users, and btrfs doesn't touch anything in the kernel tree outside of itself, so there's no chance of regressions for non-btrfs users.

In userspace, it'd be a good idea too to update btrfs-tools to Chris's git branch too, which adds the delete snapshot support in userland, but that's a much more minor concern compared to the kernel aspect of this.

Andy Whitcroft (apw) on 2009-11-30
tags: added: kernel-series-unknown
tags: added: karmic
removed: kernel-series-unknown
Jeremy Foshee (jeremyfoshee) wrote :

Hi John,

This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 481404

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-kernel-logs
tags: added: needs-upstream-testing
tags: added: kj-triage
Changed in linux (Ubuntu):
status: New → Incomplete
Iain Buclaw (ibuclaw) wrote :

Thanks for the canned response, not sure why you added 'needs-kernel-logs', as is completely irrelevant to the nature of the report, so removing it.

And no, the 2.6.32 kernel in the development version of Ubuntu (Lucid) does not exhibit the btrfs bugs stated that are present in the 2.6.31 kernel in the current version of Ubuntu (Karmic). But again, I think this is completely irrelevant to the nature of the report, besides it has already been expressed clearly in the original report.

In my opinion, I think it would be a good idea to have a separate btrfs-kernel-source package that has the most recent git version of btrfs that is still compatible with the kernel in Ubuntu. That way, if users wish to have a more up to date version of the file system driver, which will include more bug fixes and features, they have the choice to.

The way it works is no different to, say how nvidia-kernel-source inserts itself as a module into the kernel via dkms, and you can see a proof of concept package in my ppa that has been up since around December (with one or two minor changes since then). https://launchpad.net/~ibuclaw/+archive/ppa

Regards

tags: removed: needs-kernel-logs needs-upstream-testing

As Iain said,

I filed this bug in the early stages of Karmic hoping that I could talk a kernel developer into pulling the btrfs tree. By now, it's not really that relevant anymore, as Lucid comes with a fairly recent btrfs implementation and the population that'd care about btrfs probably would have adopted Lucid already.

The addition of a btrfs-kernel-source DKMS package would be great, and something to look into doing for lucid+1 if btrfs doesn't stabilize more by then.

So, as far as I'm concerned, this bug is no longer relevant and can be closed.

On Apr 24, 2010, at 12:55 PM, Iain Bucław wrote:

> Thanks for the canned response, not sure why you added 'needs-kernel-
> logs', as is completely irrelevant to the nature of the report, so
> removing it.
>
> And no, the 2.6.32 kernel in the development version of Ubuntu (Lucid)
> does not exhibit the btrfs bugs stated that are present in the 2.6.31
> kernel in the current version of Ubuntu (Karmic). But again, I think
> this is completely irrelevant to the nature of the report, besides it
> has already been expressed clearly in the original report.
>
> In my opinion, I think it would be a good idea to have a separate btrfs-
> kernel-source package that has the most recent git version of btrfs that
> is still compatible with the kernel in Ubuntu. That way, if users wish
> to have a more up to date version of the file system driver, which will
> include more bug fixes and features, they have the choice to.
>
> The way it works is no different to, say how nvidia-kernel-source
> inserts itself as a module into the kernel via dkms, and you can see a
> proof of concept package in my ppa that has been up since around
> December (with one or two minor changes since then).
> https://launchpad.net/~ibuclaw/+archive/ppa
>
> Regards

Changed in linux (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers