btrfs in the kernel 2.6.31

btrfs in the kernel 2.6.31

[Eugene Crosser]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

Hello all,

sorry for a user-level question,

I have a board based on PLX7821 aka OX820 ARM SoC. It is not supported in the
mainline kernel; the vendor supplied the source of the kernel 2.6.31 with
necessary updates for this platform, and it works. I understand that there have
been no successful attempts to bring support of this platform to newer kernels.

I would like to use btrfs on this system, but it is labelled "experimental" in
the kernel. My question is: is it "safe" to use btrfs as it is in 2.6.31? In
other words, where there "data destroying" bugs found and fixed since then? If
the answer is yes, then is it possible (and how difficult) to compile newer
btrfs code against this kernel, or backport the fixes?

Thanks,

Eugene


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: btrfs in the kernel 2.6.31

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

On Tue, Dec 18, 2012 at 06:11:55PM +0400, Eugene Crosser wrote:
> I have a board based on PLX7821 aka OX820 ARM SoC. It is not
> supported in the mainline kernel; the vendor supplied the source of
> the kernel 2.6.31 with necessary updates for this platform, and it
> works. I understand that there have been no successful attempts to
> bring support of this platform to newer kernels.

> I would like to use btrfs on this system, but it is labelled
> "experimental" in the kernel. My question is: is it "safe" to use
> btrfs as it is in 2.6.31? In other words, where there "data
> destroying" bugs found and fixed since then? If the answer is yes,
> then is it possible (and how difficult) to compile newer btrfs code
> against this kernel, or backport the fixes?

   2.6.31 is *insanely* old in btrfs terms, and definitely contains
serious filesystem-corrupting bugs that have been fixed since. You
should be looking at running 3.7 (right now) or 3.8-rc1 (when that
comes out next week), from a btrfs point of view. I really wouldn't
recommend running the btrfs code from 2.6.31.

   Backporting current btrfs code to a kernel that old is likely to be
a difficult proposition, simply because other things (in the VFS and
block layers) will have changed underneath it. Similarly, if the
patches for your board haven't been updated as the kernel progressed,
you're going to have a hard time forward-porting them. Given the
option of where to put in the work, I'd recommend forward-porting the
hardware support to a more recent kernel, and getting that pushed to
mainline, as it's more likely to be useful in the future, and useful
to more people.

   Hugo.


-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- Our so-called leaders speak/with words they try to jail ya/ ---   
        They subjugate the meek/but it's the rhetoric of failure.        
                                                                         

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: btrfs in the kernel 2.6.31

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]

On Tue, Dec 18, 2012 at 02:35:21PM +0000, Hugo Mills wrote:
> On Tue, Dec 18, 2012 at 06:11:55PM +0400, Eugene Crosser wrote:
> > I have a board based on PLX7821 aka OX820 ARM SoC. It is not

   Oh, I forgot to mention -- there's some problems with the btrfs
userspace tools on ARM, related to unaligned accesses. You will need
to get hold of the patch (from Arne, in October this year, on this
mailing list, shout if you can't find it) which fixes those issues.
It's not made it to the upstream btrfs-progs repo yet.

   Hugo.

> > supported in the mainline kernel; the vendor supplied the source of
> > the kernel 2.6.31 with necessary updates for this platform, and it
> > works. I understand that there have been no successful attempts to
> > bring support of this platform to newer kernels.
> 
> > I would like to use btrfs on this system, but it is labelled
> > "experimental" in the kernel. My question is: is it "safe" to use
> > btrfs as it is in 2.6.31? In other words, where there "data
> > destroying" bugs found and fixed since then? If the answer is yes,
> > then is it possible (and how difficult) to compile newer btrfs code
> > against this kernel, or backport the fixes?
> 
>    2.6.31 is *insanely* old in btrfs terms, and definitely contains
> serious filesystem-corrupting bugs that have been fixed since. You
> should be looking at running 3.7 (right now) or 3.8-rc1 (when that
> comes out next week), from a btrfs point of view. I really wouldn't
> recommend running the btrfs code from 2.6.31.
> 
>    Backporting current btrfs code to a kernel that old is likely to be
> a difficult proposition, simply because other things (in the VFS and
> block layers) will have changed underneath it. Similarly, if the
> patches for your board haven't been updated as the kernel progressed,
> you're going to have a hard time forward-porting them. Given the
> option of where to put in the work, I'd recommend forward-porting the
> hardware support to a more recent kernel, and getting that pushed to
> mainline, as it's more likely to be useful in the future, and useful
> to more people.
> 
>    Hugo.
> 
> 

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- Our so-called leaders speak/with words they try to jail ya/ ---   
        They subjugate the meek/but it's the rhetoric of failure.        
                                                                         

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: btrfs in the kernel 2.6.31

[Eugene Crosser]

[-- Attachment #1: Type: text/plain, Size: 2823 bytes --]

Thanks Hugo!

The idea to bring the hardware support forward to the current kernel was my
first thing to check. It seems that a few people (more experienced than myself)
tried this and could not make it work reliably. Tweaking btrfs in 2.6.31 was my
"plan B". Now it looks like both endeavours are beyond my knowledge/resource
budget. Oh well.

Generally, the idea of using btrfs on a home NAS is very attractive: fast
initialization of raid1 and especially filesystem-level snapshots are exactly
what I want from my file server.

Thanks again,

Eugene

On 12/18/2012 06:37 PM, Hugo Mills wrote:
> On Tue, Dec 18, 2012 at 02:35:21PM +0000, Hugo Mills wrote:
>> On Tue, Dec 18, 2012 at 06:11:55PM +0400, Eugene Crosser wrote:
>>> I have a board based on PLX7821 aka OX820 ARM SoC. It is not
> 
>    Oh, I forgot to mention -- there's some problems with the btrfs
> userspace tools on ARM, related to unaligned accesses. You will need
> to get hold of the patch (from Arne, in October this year, on this
> mailing list, shout if you can't find it) which fixes those issues.
> It's not made it to the upstream btrfs-progs repo yet.
> 
>    Hugo.
> 
>>> supported in the mainline kernel; the vendor supplied the source of
>>> the kernel 2.6.31 with necessary updates for this platform, and it
>>> works. I understand that there have been no successful attempts to
>>> bring support of this platform to newer kernels.
>>
>>> I would like to use btrfs on this system, but it is labelled
>>> "experimental" in the kernel. My question is: is it "safe" to use
>>> btrfs as it is in 2.6.31? In other words, where there "data
>>> destroying" bugs found and fixed since then? If the answer is yes,
>>> then is it possible (and how difficult) to compile newer btrfs code
>>> against this kernel, or backport the fixes?
>>
>>    2.6.31 is *insanely* old in btrfs terms, and definitely contains
>> serious filesystem-corrupting bugs that have been fixed since. You
>> should be looking at running 3.7 (right now) or 3.8-rc1 (when that
>> comes out next week), from a btrfs point of view. I really wouldn't
>> recommend running the btrfs code from 2.6.31.
>>
>>    Backporting current btrfs code to a kernel that old is likely to be
>> a difficult proposition, simply because other things (in the VFS and
>> block layers) will have changed underneath it. Similarly, if the
>> patches for your board haven't been updated as the kernel progressed,
>> you're going to have a hard time forward-porting them. Given the
>> option of where to put in the work, I'd recommend forward-porting the
>> hardware support to a more recent kernel, and getting that pushed to
>> mainline, as it's more likely to be useful in the future, and useful
>> to more people.
>>
>>    Hugo.
>>
>>
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: btrfs in the kernel 2.6.31

[Valentin QUEQUET]

Hi Eugene,

You may want to port up-to-date User-Mode-Linux to the ARM platform (at least
yours), and then run your custom UML-powered file server with support for all
the  improved features of BTRFS per Linux 3.7.

Hope this helps.

Regards,
Valentin