c3po Posted February 5, 2016 Share Posted February 5, 2016 Hi, as I am testing ARMBian (Vanilla Kernel) and also testing to set up a reliable Seafile server on my banana Pi, I would like to hear some opinions from the Pro's here (Igor, tkaiser, zador.blood.stained) I'm thinking of choosing btrfs for my data SSD hooked on SATA port and here I am not sure about following questions: * Trim support * performance compared to ext4 writing reading especially smaller chunks (seafile makes chunks out of big files) * reliability? I can hardly find any info regarding "ARMBian and btrfs" * Current drawbacks? May be btrfs is not the right choice for servers like Seafile? * Is btrfs good for SSD? May be it has more indirect write accesses and stresses the SSD's memory cells way more than ext4? My expectations from btrfs: (having read this: http://linux-sunxi.org/Sunxi_devices_as_NAS#New_opportunities_with_mainline_kernel) I hope that read and write performance could raise a bit compared to ext4? on the fly file compression (resulting in higher throughput? Less CPU load during compression (which algorithm would be best for Banana PI?) higher data integrity (but I am not sure how I could get informed by the server if something odd happens with the data) So as you see I just lack a lot of information about the BTRFS status in ARMBian. I hope somebody here can help me out with some answers Have a nice day everybody! Link to comment Share on other sites More sharing options...
tkaiser Posted February 5, 2016 Share Posted February 5, 2016 So as you see I just lack a lot of information about the BTRFS status in ARMBian. Maybe that's due to a missing relationship between btrfs and Armbian? The state of btrfs (amount of bugs fixed, performance, stability) depends on the kernel version you use. As a rule of thumb: the higher the kernel version the better the btrfs support. Therefore it makes absolutely no sense to collect a knowledge base regarding btrfs+Armbian since all the informations are already available somewhere else. IMO there are four things to consider when using btrfs on the boards we support: never use btrfs for important data with old kernel releases. Use mainline never use btrfs scrubbing together with redundancy and 'automatic failure correction' on systems that lack ECC RAM (applies to every device Armbian supports). When you can't rely on DRAM contents scrubbing might corrupt data that was ok before! btrfs transparent file compression might increase throughpout when I/O bandwidth is the bottleneck (USB, SATA write with A10/A20 devices) btrfs transparent file compression might decrease throughput when CPU utilisation is already the bottleneck (you should never try GZIP on slow ARM devices, only lzo/lz4) One real problem 'for' btrfs is that informations are scattered through various places and are mostly outdated (same applies to 'knowledge' or 'best practices' regarding SSDs, eg. there exist still people that try to prevent swap files being written to SSD since they refuse to understand wear-leveling). I would suggest doing some tests on your own and starting with 'compress,noatime,discard' as the only mount options (SSD detection works since ages but does not turn TRIM on automagically). And a final note: You should never forget that Linux is an operating system targeted also at servers. There are a few abstraction layers between the SSD cells (some inside the SSD -- the flash transaction layer implementing wear-leveling, garbage collection and so on -- some in the OS in the form of buffers, filesystem semantics like 'CoW' and so on) and the representation of data. Monitoring accesses at the filesystem and at the blockdevice layer looks significantly different. Link to comment Share on other sites More sharing options...
tkaiser Posted February 5, 2016 Share Posted February 5, 2016 And you always should keep in mind: 100% of all commonly used benchmarks are just wrong. Without a deeper understanding and an 'active benchmarking' approach you will always end up with misleading results and draw the wrong conclusions. A great source of information is provided by one of my personal heroes: http://www.brendangregg.com/activebenchmarking.html http://slideshare.net/brendangregg/linux-performance-analysis-and-tools http://slideshare.net/brendangregg/broken-linux-performance-tools-2016 2 Link to comment Share on other sites More sharing options...
c3po Posted February 5, 2016 Author Share Posted February 5, 2016 Thanks a lot tkaiser! I thought may be somebody has any issues to report or so, or concerns about using it . This is because I ran into trouble with systemd yesterday and did not know that it was disabled in ARMBian. Made me a lot of headache until I found some notes here in the forum Link to comment Share on other sites More sharing options...
matt Posted February 5, 2016 Share Posted February 5, 2016 Hello! I am using BTRFS with Bananian and Armbian. (3 Banana Pies: 4x external USB hard drives, 1x SATA SSD… everything with BTRFS) Armbian with an external SSD (SATA): root@bananatest:~# uname -a Linux bananatest 4.3.3-sunxi #3 SMP Mon Dec 28 11:27:16 CET 2015 armv7l GNU/Linux root@bananatest:~# dpkg -l | grep btrfs ii btrfs-progs 4.2-1 armhf Package created with checkinstall 1.6.2 root@bananatest:~# btrfs --version btrfs-progs v4.2 root@bananatest:~# mount | grep btrfs /dev/sda1 on /mnt/BTRFS_POOL_SSD type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/) /dev/sda1 on /mnt/Data type btrfs (rw,relatime,ssd,space_cache,subvolid=257,subvol=/@Data) root@bananatest:~# cat /sys/block/sda/queue/rotational 0 I am still using btrfs-progs 4.2 (self-compiled). It's working good (compression: lzo and zlib, subvolumes, snapshots, scrub, checksums). If you want to use compression, you should use lzo. With BTRFS I was able to detect a buggy USB hard drive controller. 1 Link to comment Share on other sites More sharing options...
Recommended Posts