* Re: Usage in embedded projects
2012-04-12 1:08 Usage in embedded projects Roman Shaposhnik
@ 2012-04-12 3:19 ` Duncan
0 siblings, 0 replies; 2+ messages in thread
From: Duncan @ 2012-04-12 3:19 UTC (permalink / raw)
To: linux-btrfs
Roman Shaposhnik posted on Wed, 11 Apr 2012 18:08:47 -0700 as excerpted:
> after attending Chris' presentation at Linux Foundation Summit I got
> really excited about the potential for using btrfs in some of the
> embedded projects that I do. With that in mind, here's a couple of
> question (feel free to vector me off to an FAQ ;-)):
> * does anybody on this list have any experience with btrfs in the
> embedded space?
> OpenWRT/OpenEmbedded or anything else? Most of my projects are MIPS
> (some are ARM).
> * what's the kernel/userland versions that I should start with?
> * is there any reason for a restriction to the size of the device
> (>=256 MB)?
> 256MB is a lot for an embedded application.
I claim no embedded knowledge and actually am waiting for a particular
feature that's not in mainline yet so I'm not actually running btrfs here
yet, but you asked for a FAQ and didn't mention the existing ones or the
wikis in general, so...
There's actually two wikis ATM, the static and quite dated (from pre-
kernel.org-breakin) but official looking kernel.org URL wiki, and a
"temporary" one created in the wake of the breakin that's looking like it
might ultimately be permanent. Here's the links for both...
outdated: https://btrfs.wiki.kernel.org/
current: http://btrfs.ipv5.de/index.php?title=Main_Page
Some quick points:
AFAIK, the 256 MB minimum is gone with 3.2 or so. You *WILL* want the
equally recent mixed-mode (data/metadata mixed together), however, for
something that small, but it's now the default under a gig anyway. (I
know this one since that was one of the issues I asked about while
planning my own eventual upgrade... I currently have a 128 MB /boot
partition.)
FWIW, btrfs' default is single-mode data, dup-mode metadata. You can
read more about it on the wiki, but for smaller filesystems, you may not
have room for the duped metadata. And if you're not duping metadata
anyway, you may wish to consider whether you want checksumming at all,
thus reducing metadata size further. It /may/ also affect speed on
embedded platforms, tho it's not so much a factor for non-embedded. But
that of course kills one of the big selling points of btrfs, its
automatic checksumming and error detection/correction. There's other
similar mount option and etc tradeoff choices to make, too, so pay
attention to those bits on the wiki.
Kernel and btrfs-tools versions? btrfs is still under very heavy
development, with bugs actively being reported, tracked down and fixed
here on this list. As such, the general rule is to run the newest
versions possible and to actively follow this list for current
developments. That normally means following the latest linus-mainline
kernel release, if not the rcs, if not the btrfs-next branch pre-
integration with mainline. If you're running more than a version behind,
that's normally considered OLD and of little testing value (if you've
kept up, that's all btrfs is considered ready for now, testing, official
oracle, etc, support not withstanding), as a lot of bugs have been fixed
since then, while others may well have just been exposed and need testing
to trigger and then reported.
If you've noted, I said "normally". There's apparently an active
regression in 3.3, and while 3.4 may correct it, there's another active
regression there, tho they've traced it and should have a fix in by 3.4-
rc4 or so. Of course the last few weeks of list archives have the
details, thus the emphasis on keeping up with current status on the list,
but at the moment there's an exception to the general "absolute
latest" (unless you want to try the btrfs-next tree), and you might want
to stick with the latest stable 3.2.x for a couple weeks.
If from that you get the picture that btrfs isn't ready for anything
besides testing data, you've been paying attention! =:^) Of course
backups are always recommended, even with stable filesystems, but btrfs
goes way beyond that. With a stable filesystem, your backup is just
that, a backup to your "real" data. With current btrfs, the best
approach is to consider anything on btrfs testing-only throw-away
temporary data. You really SHOULD be considering the data on another non-
btrfs volume your primary data, with it backed up as you would any data
you value, and the copy you're testing btrfs with exactly what I said
above, testing-only, no big deal if btrfs eats it, because testing for
and reporting that sort of thing are ideally exactly why you're running
btrfs at this point anyway.
If that hasn't scared you way yet, welcome to btrfs testing, have a read
of the wiki and a couple weeks of btrfs list archives to get oriented,
and looking forward to seeing your reports of any issues you find with
embedded use specifically, but in general as well. =:^)
Alternatively, you may wish to do what I'm doing ATM, continue following
the list to keep updated, but hold off on actual testing for the moment.
(In my case, the feature I'm waiting for is N-way mirroring, at least
three-way. The current so-called raid1 mode is in reality only two-way-
mirroring, not N-way, with either 3-way or N-way (I'm not actually clear
which) roadmapped for 3.5 or 3.6 at this point. Another thing I was
waiting for was an actual error-correcting btrfsck, which is only now
coming available, so it's coming, but I have 1-2 kernel cycles to wait
for my critical feature, which is fine with me, since btrfs is starting
to mature now and should be much improved in that time, thus less risk
and hassle for me. =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 2+ messages in thread