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
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.
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 notOh, 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.
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. >> >> >
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html