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:
signature.asc
Description: OpenPGP digital signature
