Posted on 05/28/2014 12:14:45 PM PDT by re_nortex
Sure there are technical forums that discuss btrfs, the shiny new filesystem for Linux but my experience has shown that FReepers meet or exceed the technical expertise anywhere on the net. The two cutting-edge filesystems that are (supposedly) impervious to bitrot are btrfs and zfs (which has a Linux implementation, older than what Oracle has now closed off).
My main interests aside from data integrity are snapshots and the ability to boot from such a snapshot. That's afforded by beadm on Solaris which uses a zfs snapshot behind the scenes.
Any thoughts, opinions or comments based on experience with btrfs and/or zfs on a Linux platform?
The biggest pro I see so far (only been a few months) is that fsck takes virtually no time at all.
Another thing I've noticed (and this seems odd to me) is that my custom partitioning schema usually involves a separate partition for /,/home,etc. but "df -h" typically shows both / and /home as sharing the same device/partition. Not sure yet what that is all about.
If you plan on using zfs I have found by painful experience you need to have an enormous amount of memory. I am currently running with zfs and it takes 20G of memory to really support it well.
bookmark for later
Thanks for the speedy response and for the ping to all the experts here on Free Republic.
I'm just now getting acquainted with btrfs and, so far, am confining my still-early learning to a VM. As far as fsck is concerned, it appears that best practice is to set the pass to 0 in /etc/fstab. From what I gather (and there's a lot of information on the 'net, some contradictory) is that btrfs doesn't need a filesystem check. That's similar to zfs in that the only manual maintenance required is the occasional scrub operation.
I hope I'm not making the mistake of transferring my fairly good knowledge of zfs into the new realm of btrfs. They are different but for a n00b like me, similar enough to be a tad confusing. :)
I can confirm that's the certainly the case on Linux. The process table has a lot of "z.*" items running for sure when using the zfs filesystem. Since Oracle has ceased open source development on zfs, that's why I've started exploring btrfs as an alternative.
I really like the ease of handling boot environments in Solaris with the beadm tool (written in Python, by the way) and am seeking something roughly akin to that with btrfs in Linux land.
While the zfs on Linux crew is doing a laudable job, their last release is from August 2013 whereas btrfs is more recent, albeit a fast-moving target.
Both have strengths. ZFS has very nice snap shot technology but the draw back is zfs is not native to the kernel (this could have changed, it’s been a long while since I’ve read the commits) so it takes a good chunk of memory since it is “user space”. btrfs has an excellent journal type recovery method and is well suited for VERY large filesystems.
If it’s just your local system and a couple TB, ext4 still fits a good mold.
Was just about to ask about comparison to ext4... you pretty much answered though ;^)
Thanks for the reply. In fact, ext4 is still my day-to-day default choice for every filesystem on bare metal. I do layer it atop LVM for snapshots -- which has saved my bacon countless time. Most recently, a careless rm -rf /usr/lib (when I meant to type rm -rf /usr/libx32, a no-longer used directory on my system) would have been disaster without the snapshot.
That said, if btrfs affords such capability without the LVM underpinnings, I may move that way. For now, I'm just exploring it in the anything-goes playpen afforded by a VM.
That paper that you linked to is one I hadn't encountered. It's a cut above the usual stuff and is being printed to some dead trees for thorough reading, yellow highlighting and my marginal notes. So thanks again.
You should always run 'rm' and 'mv'with a following '-i'. This will prompt you with an "are you sure?" question before they execute the command.
My startup scripts have aliases in them for powerful commands;
alias remove='rm -i'
alias move='mv -i'
But you probably already know this. I learned the hard way too.
I've got to admit that snapshotting has made me work without a net, as it were. Knowing that a fat-fingered mishap is so readily recovered allows me to live life on the edge. I now laugh in the face of danger!
Fine print: Or at least on my own machines. On customer systems, I'm a coward. :)
Agreed there.. even with LVM (encrypt)... STILL need back-up.. learned that the hard way... power outage while I was writing to encrypted HD (whole HD, not file or folders).. Screwed up the encrypted HD.. spent 6 months trying to find a way to read it again.. gave up last week.. and did low lvl format :/ (and then partitioned with ext4)...
(Was not home or boot HD..)
Yes.. more help here than even on Mint site :/ Takes weeks (if mot months) to get an answer there :/
At least many here will tell us if they have no idea what to do :p
I run btrfs on both a physical laptop and a VM.
Definitely smarter than the lefty stuff.
Yes, that document is pretty stout.
Allow me to disabuse you of the notion: "Are you logged in?"
If looking for discussions, etc., I'd start with Hacker News threads, e.g. btrfs or btrfs vs zfs. Or sample StackOverflow questions.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.