File systems are one of those things that typical end users don’t think much about. Apparently, [seaQueue] isn’t a typical end user. He’s posted some instructions on how to run an alternate file system–btrfs–on the Raspberry Pi.
The right file system can make a big difference when it comes to performance and maintainability of any system that deals with storage. Linux, including most OSs for the Raspberry Pi, uses one of the EXT file systems. These are battle-hardened and well understood. However, there are other file systems, many of which have advanced features superior to the default file system for some applications.
Btrfs, often pronounced “butter eff ess”, begin life at Oracle and was born from an idea in an IBM paper. It offers advanced features like pooling, snapshots, and the ability to fuse multiple devices into one logical device. One notable feature the file system offers is copy-on-write. That means file copies can share common blocks as long as they stay common. Compression is available, as is seeding a file system with read-only storage, which could be very useful in some embedded systems. You can also configure several types of RAID using nothing but btrfs. You can see a video presentation about features of btrfs below.
The post by [seaQueue] suggests an 8 GB SD card, although you can apparently barely squeeze onto a 4 GB card. He also points out that btrfs doesn’t support swap files (but you can create a dedicated swap partition) and that certain workloads can cause a lot of writes which might be bad for SD cards and other solid state storage. He suggests you could use an SSD instead of an SD card or USB drive, and this apparently offers better wear leveling.
Do you need this kind of power on a Raspberry Pi? Maybe not. But it is still a good tool to have at your disposal. We can imagine systems where being able to span multiple volumes, do snapshots for backups, and implement RAID could come in handy.
If you’d rather hack your own file system, that’s possible too. A whole file system is a big job, but with FUSE you can create simple file systems that do things like front for an ssh connection or a compressed archive file. The original Unix philosophy was that everything should be a file. Modern developers have moved away from that to some degree, but you still see occasional examples.
Maybe F2FS? It’s literally designed to be Flash Friendly.
That’s what I use on my systems. When you use Arch Linux ARM, you make the partition yourself so it’s trivial to change FS. There just has to be a kernel module for it, and the stock one already includes btrfs and f2fs.
All hype no substance. Not surprising considering it’s software that originates from Samsung.
The only file system in over a decade to suffer unrecoverable corruption that caused the goddamn fsck utility to crash, I’ll never touch that shit again.
It also doesn’t actually perform any better – it uses shady tricks (such as a hidden writeback cache) to be awesome in benchmarks, so awesome the numbers are impossible. (I can’t find the specific Phoronix article where this was found right now, it’s a few years old, but f2fs was benchmarking as being faster than the underlying hardware was capable of.) Those numbers hinting and shady caching are consistent with my experiences of it being unusually prone to severe corruption.
Got any info on good filesystems for flash storage – SD card, NAND etc.?
How to systematically narrow down an architecture (ARM) to a specific platform (Raspberry Pi) ? Use an HaD author´s mind filter.
I don’t follow. The linked post is, literally, step-by-step instructions on setting up BTRFS for a Raspberry Pi. How was that supposed to be general to all ARM devices?
Maybe, he’s wishing all arm devices were just a simple plug-n-boot affair… Like most x86 devices:
I say, “most” because there are bespoke x86 configurations that are plain locked down or fixed-firmware.
sounds more like “BTRFS runs on every arm, not just the PI” complaint.
The Raspberry Pi is a great example of a hobbyist arm processor. Everyone has one. For the most part, they can be modded excessivly, unlike the processer running in your phone. If you were a dev with enough experience to get that level of control over their device.
Jfs and xfs are what you want!
Last time I tried BTRFS on an older (below 2 GHz, single core) notebook, it dramatically slowed down that system compared to using EXT4FS. Later I tried BTRFS “RAID” on 4 to 6 USB flash drives with Cubie3 and PI2 and it reliably crashed on both of them after some minutes…
It still needs some time to heal this trauma before I touch BTRFS again… but some day I will…
I have heard anecdotal catastrophic fail stories about btrfs, and it certainly would be advisable to have a /root ext4 root with a forced fsck on boot (Raspbian lenny should be setup this way already.)
btrfs does not have the same features of ZFS, and has undergone several changes over the years.
Mirror ZFS log/cache-device are robust on flash
http://docs.oracle.com/cd/E26502_01/html/E29022/chapterzfs-flash.html
(ZFS snapshots are cheap, but don’t enable deduplication on a Pi)
In general, the root OS partition should still be setup for read-only operation on boot (even if you regularly modify the data), and the paths that get regularly modified ( like /var/* /home/* /tmp /run and a second copy of /dev /sys /proc mounted at boot ) moved to a secondary partition file-system path with bind mounts. This can speed up access on some sdcard flash as reads are no longer blocked by slow pending block writes to a single file system.
Thus on system crash, all recovery utilities are available if the forced auto-repair fails.
Modern high density USB drives are not rated for as many writes as flash, and can start dropping blocks in less write cycles.
SLC – (Single Level Cell). 1bit/cell.
high speed,long life time, erased about 100000times
MLC – (Multi Level Cell).2bit/cell
normal speed, normal life time, erased about 5000~10000times
TLC – (Trinary Level Cell). 3bit/cell
slow speed,cheap price,erased about 500times
Indeed, ZFS (on FreeBSD) is a wonderful filesystem. I think FreeNAS, built on FreeBSD, uses ZFS under the hood. I love the snapshots, and also the ability to protect against bitrot with checksums. You can even do a single-drive with “copies=2” and use a drive as its own mirror – obviously, drive failure can still hit, but the files have individual backups.
and how it can be used (ZFS i mean) on a Pi ?
There is a FreeBSD port for RPi. If you want to stick to Linux, then you’ll have to use btrfs or similar.
GMailFS!!!
WsrFS (Worser File System)
so how to update to a new kernel + initrd than ?
Thanks
seems that is not possible to use a RAID1 btrfs (2 disks) in fstab, seem we lack something from initrd (btrfs device scan ?)