Other Btrfs on FreeBSD

M

Markov

How well is Btrfs supported? Can I use it as my main filesystem without the need for any strange hacks to make it run that might cost performance or introduce potential problems?

Edit: I added these three main reasons to this opening post, I had mentioned them further down this thread first:

-I really liked the Btrfs features not found in ZFS mentioned in this article http://arstechnica.com/information-...nd-atomic-cows-inside-next-gen-filesystems/3/ - especially the possibility to live-add or remove devices to the pool (online-balancing).
-I was dreading the RAM requirements of ZFS, where Btrfs seems to need much less RAM for certain tasks. I read some horror stories if you don't have exorbitant RAM amounts, especially for RAID.
-Last but not least I checked out some benchmarks here http://www.phoronix.com/scan.php?page=article&item=zfs_ext4_btrfs&num=2 in which Btrfs seems to score much better.
 
Not supported at all by the base FreeBSD operating system. If someone implements a FUSE module for Btrfs and ports it to FreeBSD that's just about the only way to have it supported.
 
It is not supported. FreeBSD isn't Linux.
FreeBSD supports many filesystems. Only ufs and zfs are recommended as main filesystems on a FreeBSD machine.
Also, btrfs is a very young filesystem, you are advised to keep extensive backups - there might be undiscovered bugs in btrfs.
 
There's also the inconvinient fact that Btrfs is GPL-licensed, it has a snowballs's chance in hell to be included in FreeBSD base.
 
ZFS originally came from Solaris and it is included in FreeBSD base system. It's very mature and stable file system than BTRFS.
 
The reduced hype for BTRFS and the growing popularity of the ZOL project would suggest that FreeBSD supports BTRFS about as well now as Linux might in 10 years.
 
Well, there were basically three reasons why I was aiming for Btrfs,
-I really liked the Btrfs features not found in ZFS mentioned in this article http://arstechnica.com/information-...nd-atomic-cows-inside-next-gen-filesystems/3/
-I was dreading the RAM requirements of ZFS, where Btrfs seems to need much less RAM for certain tasks. I read some horror stories if you don't have exorbitant RAM amounts, especially for RAID.
-Last but not least I checked out some benchmarks here http://www.phoronix.com/scan.php?page=article&item=zfs_ext4_btrfs&num=2 in which Btrfs seems to score much better.
 
Markov said:
How well is Btrfs supported? Can I use it as my main filesystem without the need for any strange hacks to make it run that might cost performance or introduce potential problems?
Click to expand...
Btrfs is Linux vaporware. It doesn't exists except in the wet dreams of Linux teens. FreeBSD shamelessly stole ZFS from Solaris but if you are really for a nice BSD modern file system try HAMMER on DragonFly. It has minuscule resource requirements and fine granulated history unlike ZFS.
 
  • Thanks
Reactions: ASX
Markov said:
I was dreading the RAM requirements of ZFS, where Btrfs seems to need much less RAM for certain tasks. I read some horror stories if you don't have exorbitant RAM amounts, especially for RAID.
Click to expand...
Only if you enable features like dedup. My 10TB RAID-Z works just fine on a machine with 4GB of memory. Just don't expect any stellar performance when you don't have a lot of RAM. ZFS likes RAM, a lot of it, but will work just fine when there's very little.
 
Oko said:
Btrfs is Linux vaporware. It doesn't exists except in the wet dreams of Linux teens. FreeBSD shamelessly stole ZFS from Solaris but if you are really for a nice BSD modern file system try HAMMER on DragonFly. It has minuscule resource requirements and fine granulated history unlike ZFS.
Click to expand...
Lmao, nice troll :). SUSE Linux Enterprise 12 uses Btrfs as default. Facebook is testing it in production. RHEL 7 is offering Btrfs as an option.
 
ZFS really loves memory because it's heavily read optimized and relies on its very efficient ARC cache to deliver the read performance it's famous for. It can be however used with limited amounts of system memory (as low as 1GB with some tuning) but it's a bit pointless to use on low memory systems if the other nice features of ZFS ( for example snapshots and volume manager) are not really needed.
 
Well, I'm still a bit concerned about the missing 'online-balancing' feature of Btrfs (able to add or remove devices to the storage pool while the system is actually live), but I guess I might try FreeBSD with ZFS for now. As you suggested, I will not use 'dedup' then, to keep RAM requirements sane. Those benchmarks I linked a bit, but maybe the performance difference compared to Btrfs won't really be noticable in my use cases (just a 'normal' single-user system, using some virtual machines, but no heavy database usage, one of the main drawbacks to Btrfs in those benchmarks), we'll see. Thanks for the replies.
 
Markov said:
I really liked the Btrfs features not found in ZFS mentioned in this article
Click to expand...

ZFS does have limitations/drawbacks. They are real. However, they're really not that strict, and are also mitigated or eliminated with proper planning. Proper planning of course requires that one is familiar with what ZFS is, how it works, and how it interacts with the rest of the OS-and-hardware ecosystem, so some learning and experimentation would be in order before finally settling on a storage setup for long-term use. But as I see it, the features mentioned in that Ars Technica article are non-essential. ZFS handles LZ4 compression dynamically and without performance problems, so you can reasonably compress everything. "Directory-level cloning" is confusing, as any ZFS filesystem is represented as a directory and can be cloned, so... And NODATACOW falls into the same category as ZFS deduplication: great as a work-around during an urgent situation, but making your long-term storage scheme dependent on it is a terrible idea.

"Online balancing" is neat, but not a huge advantage, and also has a weird name. ZFS automatically spreads data across physical and virtual devices, both for redundancy/resiliency and for a boost in performance. (One might say it "balances" the data across the pool.) That's why you can't remove a virtual device once it's been added, and probably why removing the device afterward wasn't a huge feature priority: because adding the device improves the resiliency and performance of the pool, so why would you remove it? Again: proper planning and understanding. I'm sure plenty of us have run zfs add on a single disk and spent a day regretting it, but I'm also sure we never did it again. Also, in any storage scheme with any filesystem it's obviously only possible to remove a disk so long as doing so doesn't bring the amount of available storage below the amount of data to be stored, which means it's probably only a truly useful feature to have while first setting up a pool.

If you've been weighing the pros and cons of ZFS vs. BTRFS for a bit you might have come across this article already, but I'll post it just in case.
 
Markov said:
Lmao, nice troll :). SUSE Linux Enterprise 12 uses Btrfs as default. Facebook is testing it in production. RHEL 7 is offering Btrfs as an option.
Click to expand...
Yep, and they main reason why they fallback to Btrfs is that they can't distribute ZFS.
And by the way, who is Facebook ? a Lab who certifies filesystems ?
 
Markov said:
Lmao, nice troll :). SUSE Linux Enterprise 12 uses Btrfs as default. Facebook is testing it in production. RHEL 7 is offering Btrfs as an option.
Click to expand...
I trust 0.5 petabyte of data to ZFS. I keep my most precious data (the pictures and videos of my kids) on HAMMER (HAMMER1 to be precise). I work at Carnegie Mellon University school of computer science and I don't know of anybody at CMU, Pitt, Pittsburgh super computer center, Pittsburgh Google campus, and UBER for that matter who trusts a single byte of her/his data to BTRFS. I know lot of big data guys. Trust me. They pay my wage. Unlike I (using FreeBSD for my data storage) most people use either CentOS or Ubuntu. CentOS people are split even between ZFS (which is a third party kernel module) and XFS which is by the way default file system of RHEL but familiar to old people like me from my Silicon Graphics Indy workstation. Ubuntu people use EXT4 for root partition but XFS as a file system on hardware and software RAID because until recently EXT4 was incapable of storing more than 16 TB of data on the single volume (so much about your Linux innovations).

Linux has a big following and many things going for itself. BSDs all together are just a statistical error but one thing is for sure. Linux has a proven record of creating vaporware and half thought of technologies. That is the fact. Nothing personal.

By the way HAMMER2 is objectively speaking more usable than BTRFS and that is the work of a single (genius) programmer. I dare you to put your family photos on BTRFS OpenSuSE or however is crazy enough to enable that shit (RHEL defaults to XFS as I said but you can use BTRFS for the data partition if you are crazy).

Now above mentioned ARC cache algorithm of ZFS is IBM intellectual property and I can easily see IBM wiping entire ZFS landscape with a single lawsuit.
Oracle probably has enough in its war chest to save Solaris. FreeBSD will be dead on the spot. Since you seem a very nice guy who didn't come here to troll (first post is BTRFS vs ZFS) and bare nickname of those famous Russian mathematicians (father and son) I gave you a good technical advise.
 
Oko said:
Now above mentioned ARC cache algorithm of ZFS is IBM intellectual property and I can easily see IBM wiping entire ZFS landscape with a single lawsuit.
Click to expand...

This is interesting. Do you have a source for this? My guess is if they haven't done so they either don't care or don't have a case.
 
There is no record of IBM transferred its ARC patent to Intel. I seriously doubt IBM would want to sue over their patented ARC technology in ZFS since they're using Sun's ZFS technology in their z/OS as well so IBM and Sun had a prior agreement on sharing both technologies. IBM have a reputation for fiercely protecting their patents. PostgreSQL used to have ARC technology temporarily until IBM raised concerns over it.
 
I didn't see the links in your first post. Well, that's interesting but it doesn't change anything since prior agreements between IBM and Sun are still honored. I doubt Intel will sue or terminate the prior agreements and upset the ZFS landscape.
 
Markov said:
Lmao, nice troll :). SUSE Linux Enterprise 12 uses Btrfs as default. Facebook is testing it in production. RHEL 7 is offering Btrfs as an option.
Click to expand...
Just to add insult to injury :cool:

https://btrfs.wiki.kernel.org/index.php/Gotchas

also

It’s almost as much telling that RedHat, after years of promoting BTRFS, decided to move to XFS instead. What do RedHat and Canonical know that the entire BTRFS fandom do not?
Click to expand...

Post shamelessly stolen from a thread at one of Ubuntu forums which brags about the fact that Canonical is bringing ZFS as fully supported volume-manager/file-system in its next long term release.
 
Markov said:
How well is Btrfs supported?
Click to expand...
Before you consider the answer to that question, you need to carefully study the relative quality of Btrfs and some other file systems. My proposal would be: Go to an industry or research conference where file system and storage people hang out, engage in hallway conversations (ideally with a glass of Cabernet in your hand), and talk about that question. My personal conclusion from having done that is that I will not trust a single byte to Btrfs. The data I care about I store in FreeBSD ZFS, but I back it up (first level hourly backup to FreeBSD UFS, second level daily/weekly backup to MacOS HFS). Your mileage might vary.

I really liked the Btrfs features not found in ZFS mentioned in this article http://arstechnica.com/information-...nd-atomic-cows-inside-next-gen-filesystems/3/ - especially the possibility to live-add or remove devices to the pool (online-balancing).
Click to expand...
Add/remove devices to the pool is definitely possible in ZFS when using mirrored (not Z) RAID codes. Are you going to have enough disks to make Z codes sensible? And can you explain how the other features would help your particular use, workload, and application?

I was dreading the RAM requirements of ZFS, ...
Click to expand...
Let's see. My machine is 32 bits, has 3 gigs of RAM, and manages three ZFS pools with 4 disks total, with no problem whatsoever. Performance isn't great (I can't even max out the performance of the raw disk drives), but is still way better than what my application workload needs. Speaking of application:

Last but not least I checked out some benchmarks here http://www.phoronix.com/scan.php?page=article&item=zfs_ext4_btrfs&num=2 in which Btrfs seems to score much better.
Click to expand...
A: Performance on other people's benchmark has relatively little predictive power for your application. If you care about performance, you need to measure it yourself.
B: Do you really care about performance? Serious industrial file systems routinely operate at dozens or hundreds of gigabytes per second, yet most users are pretty happy if they can get a few megabytes per second out of their machine. For most workloads today (in particular those that normal users see), performance of the storage software stack is not a serious differentiator; the limitation tends to be application, or hardware. For some workloads, the software stack still matters, but that tends to happen in non-obvious ways.
 
BtrFS, honestly, it's not something I would use even on Linux (I am OpenSUSE user as well). After installing it, system tends to "mystically die" for some file system-related issue over a period of minutes to couple of weeks tops.

I usually go with XFS on Linux and that's all. If FreeBSD should have "new" file system support for base install, I'd vote for XFS - especially because there already is limited XFS support present in FreeBSD.
 
  • Thanks
Reactions: Oko
You must log in or register to reply here.
Back
Top