> On Sep 16, 2015, at 2:22 PM, Austin S Hemmelgarn <[email protected]> wrote: > > On 2015-09-16 12:51, Vincent Olivier wrote: >> Hi, >> >> >>> On Sep 16, 2015, at 11:20 AM, Austin S Hemmelgarn <[email protected]> >>> wrote: >>> >>> On 2015-09-16 10:43, M G Berberich wrote: >>>> Hello, >>>> >>>> just for information. I stumbled about a rant about btrfs-performance: >>>> >>>> http://blog.pgaddict.com/posts/friends-dont-let-friends-use-btrfs-for-oltp >> I read it too. >>> It is worth noting a few things that were done incorrectly in this testing: >>> 1. _NEVER_ turn off write barriers (nobarrier mount option), doing so >>> subtly breaks the data integrity guarantees of _ALL_ filesystems, but >>> especially so on COW filesystems like BTRFS. With this off, you will have >>> a much higher chance that a power loss will cause data loss. It shouldn't >>> be turned off unless you are also turning off write-caching in the hardware >>> or know for certain that no write-reordering is done by the hardware (and >>> almost all modern hardware does write-reordering for performance reasons). >> But can the “nobarrier” mount option affect performances negatively for >> Btrfs (and not only data integrity)? > Using it improves performance for every filesystem on Linux that supports it. > This does not mean that it is _EVER_ a good idea to do so. This mount > option is one of the few things on my list of things that I will _NEVER_ > personally provide support to people for, because it almost guarantees that > you will lose data if the system dies unexpectedly (even if it's for a reason > other than power loss).
OK fine. Let it be clearer then (on the Btrfs wiki): nobarrier is an absolute no go. Case closed. >>> 2. He provides no comparison of any other filesystem with TRIM support >>> turned on (it is very likely that all filesystems will demonstrate such >>> performance drops. Based on that graph, it looks like the device doesn't >>> support asynchronous trim commands). >> I think he means by the text surrounding the only graph that mentions TRIM >> that this exact same test on the other filesystems he benchmarked yield much >> better results. > Possibly, but there are also known issues with TRIM/DISCARD on BTRFS in 4.0. > And his claim is still baseless unless he actually provides reference for it. Same as above: TRIM/DISCARD officially not recommended in production until further notice? >>> 3. He's testing it for a workload is a known and documented problem for >>> BTRFS, and claiming that that means that it isn't worth considering as a >>> general usage filesystem. Most people don't run RDBMS servers on their >>> systems, and as such, such a workload is not worth considering for most >>> people. >> Apparently RDBMS being a problem on Btrfs is neither known nor documented >> enough (he’s right about the contrast with claiming publicly that Btrfs is >> indeed production ready). > OK, maybe not documented, but RDBMS falls under 'Large files with highly > random access patterns and heavy RMW usage', which is a known issue for > BTRFS, and also applies to VM images. This guy is no idiot. If it wasn’t clear enough for him. It’s not clear enough period. >>> His points about the degree of performance jitter are valid however, as are >>> the complaints of apparent CPU intensive stalls in the BTRFS code, and I >>> occasionally see both on my own systems. >> Me too. My two cents is that focusing on improving performances for >> Btrfs-optimal use cases is much more interesting than bringing new features >> like automatically turning COW off for RDBMS usage or debugging TRIM support. > It depends, BTRFS is still not feature complete with the overall intent when > it was started (raid56 and qgroups being the two big issues at the moment), > and attempting to optimize things tends to introduce bugs, which we have > quite enough of already without people adding more (and they still seem to be > breeding like rabbits). I would just like a clear statement from a dev-lead saying : until we are feature-complete (with a finite list of features to complete) the focus will be on feature-completion and not optimizing already-implemented features. Ideally with an ETA on when optimization will be more of a priority than it is today. > That said, my systems (which are usually doing mostly CPU or memory bound > tasks, and not I/O bound like the aforementioned benchmarks were testing) run > no slower than they did with ext4 as the main filesystem, and in some cases > work much faster (even after averaging out the jitter in performance). Based > on this, I wouldn't advocate it for most server usage (except possibly as the > root filesystem), but it does work very well for most desktop usage patterns > and a number of HPC usage patterns as well. See, this is interesting: I’d rather have a super fast and discardable SSD F2FS/ext4 root with a large Btrfs RAID for (NAS) server usage. Does your non-advocacy of Btrfs for server usage include a <10 user Samba NAS ? Are more details about the Facebook deployment going to be available soon ? I’m very curious about this. Regards, Vincent
signature.asc
Description: Message signed with OpenPGP using GPGMail
