Fedora 28's Grubby Could Deal With /boot On Btrfs

[phoronix]

Phoronix: Fedora 28's Grubby Could Deal With /boot On Btrfs

While Red Hat has been divesting from Btrfs and pursuing other Linux storage alternatives like Stratis, it looks like Fedora 28 will feature slightly better support for those opting for Btrfs...

http://www.phoronix.com/scan.php?page=news_item&px=Grubby-Boot-On-Btrfs

[waxhead]

This was surprising news, I was under the impression that stuff like would have been solved years ago.

I have been running a single disk BTRFS filesystem since 2013 that I have gradually added disks to. It now runs with data:raid1 and metadata:raid10. Works great!
on Debian all I have to do to remain happy is to run grub-install on all devices and the update-grub afterwards.

From my experience BTRFS works great. I now run it for my main computer with 7 disks, and for a server hosting the SOASC/SOAMC projects (look it up if you're into C64 and Amiga music) and I also run BTRFS on one of my own storage servers as well as a small netbook that is seriously out of date , but still does the job when I am out traveling.

BTRFS have corrected a few corruptions on some of these systems, and was able to survive a few mishaps like a disk controller hang and a couple of weeks ago I accidentally did the 'dd fiasco' where I overwrote one of the online disks with a opnsense image. Luckily BTRFS recognized this as bad data and used the alternative copy instead to read from and attempt to correct the bug as well. I was almost tempted to run a scrub to see if the filesystem was able to recover, but to be on the safe side I simply removed the device from the filesystem and re-added it again. No down time, everything works great and a scrub verified that all was good!

Terribly off topic perhaps, but BTRFS is a great filesystem as long as you know what you are doing and are aware of some of its (performance) limitations. If you haven't tried it - you should

[King InuYasha]

This was surprising news, I was under the impression that stuff like would have been solved years ago.

The simple stuff (like what your setup is) always worked. But implementing boot-to-snapshot is rather complicated and requires touching various parts of how the system boots, including the tool that actually sets up the kernel images and configures the bootloader (grubby).

[treba]

I still like the transparent compression but quite frankly that's the only advantage BTRFS has over other filesystems and nobody is even talking about that feature.

Well the only advantage? That just means your use-cases are very limited. Snapshots are awesome for recovery purposes, reflinks/deduplication can save massive amounts of space, especially when you have multiple users.... Heck just a couple of days ago I copied my wine prefixes so they could get used by the guest account on my laptop. They amount to 90GB, but with --reflink I could copy them in seconds and don't need any extra space. I don't need to worry about security and even if the games get patched I can just run a deduplication at some point (which is not possible with ZFS, unfortunately)

I use BTRFS on my laptop and my servers for quite some time now and while it's not yet as idiot-proof as ext4 (balancing, fragmentation), it seems to be on a good track getting there.

[Anvil]

wonder what this says for ( stratis ),

[waxhead]

I keep trying to run install-grub and grub-update, but I'm on Ubuntu.. 🤪

I still like the transparent compression but quite frankly that's the only advantage BTRFS has over other filesystems and nobody is even talking about that feature. EXT4 and F2FS fulfill all my other needs. Heck, the way things are going with 3D flash these days, regular magnetic drives will likely become obsolete in just a couple years. My next laptop will likely have two M.2 drives stripped RAID 0 via hardware... or maybe not as that might actually increase latency. In fact, the need to use RAID at all kind of goes away with those magnetic platters. Flash is just so much more reliable.

Well, I have only had bad experiences with Ubuntu, for some reason Debian "just works" while Ubuntu is a constant pain and problems. It is a few years since I tried Ubuntu so things may have changed so no comment there.

Well, the transparent compression is well known, but BTRFS have many major advantages over other filesystems. The most important one is checksumming of data and metadata, the ability to duplicate metadata and data on one single device as well as reshaping the filesystem while online and so forth. If you use BTRFS like just another filesystem like EXT4 , XFS or whatever you will in most cases be better off if you run into trouble with your devices. With non-checksumming filesystems you have no idea if a gremlin have been messing around with your bits and bytes. With BTRFS you do. And as with all other filesystems (including ZFS) you should keep backups of your data IF you value it!

[polarathene]

This was surprising news, I was under the impression that stuff like would have been solved years ago.
BTRFS is a great filesystem as long as you know what you are doing and are aware of some of its (performance) limitations. If you haven't tried it - you should

I've been interested in it but due to the broad amount of things I do with my OS, it's a filesystem I've been putting off because of how I need to think more about what I'm doing(in terms of storage either directly by me or by another software like VM or databases storing in a default locaiton). For a common user, where you don't use databases and virtual machine images, you'd still need to keep in mind that BTRFS isn't well suited for temporary media right?

Downloads folder for example would be good, where you can download various sized files, then either moving them(does that just update the location or create a copy?, is there any difference if they're moved to a different subvolume?) or deleting regularly needs to be given some thought if it's appropriate for a locationl like that to beb acked by BTRFS? Another similar location to Downloads for common users could be there Steam games. Those games can update regularly and some be fairly large, users may also have a large library where they download/install a game to play, but lack available disk space(I'm one of them with only only about 100-200GB free for games) for retaining them, so they may delete/uninstall them after a while, possibly installing the game again months later if they're in the mood for playing it again.

Another as a developer could be my projects folder where I might compile a project multiple times while working on it, or the project might do some heavy I/O, I have worked on a job where I process 10-100GB binary files, which would rewrite the data into smaller chunks organized to some parameters compared to the original order, get processed some more, then delete. During development of a program that does that, the amount of writes would be quite high, I guess it'd be clear that large files like that would be better suited for operating on via XFS for better thoroughput as the data being stored/processed isn't of value(only the original binary and the processed binary once done which can go into storage on a NAS or something). I'm aware that BTRFS lets you disable CoW but that afaik prevents many of the features BTRFS offers, so there isn't any point in disabling it vs using a different partition/filesystem for such data right?

Another one as a developer is git projects. If I clone that or have my own, the `.git folder, should that really be on BTRFS? Does it cause any issues with switching branches which I think deletes/copies files in the project folder from the .git directory(kinda like a database isn't?). What about large packages, UnrealEngine4 is huge, I think it requires 100GB to compile, is that going to be a problem with each update, it's not something I could fit into tmpfs.

---

That'd be a fairly good set of examples/concerns I have. I did try BTRFS out briefly with openSUSE in 2016 but on small embedded x86 system with only 16GB SSD available I think(maybe 32GB). I used Docker(with BTRFS driver) but not under production, I was developing on it rebuilding docker images quite a bit which due to BTRFS as the FS caused an out of space issue much faster, required a balance or scrub, can't recall, to remove the data that was no longer on the system but BTRFS was holding onto.

I'm not sure if you've had to deal with any of those issues above, but would you have advice on how to if using BTRFS? I find Snapshots especially with Snapper quite appealing, they conflate the problem though don't they as the snapshots can hold onto deleted data preventing it from being properly cleaned unless the snapshot is removed(rightfully so).

I think the biggest issue with it, is that when deleting it does keep the copy/history still, which isn't necessary to enjoy all the other benefits of BTRFS? Is there a way to disable that feature, at least selectively(perhaps to subvolumes)?

The reflinks feature you gave an example for, I guess you don't get that by default if you do a file copy? Dedup handles that I guess?(it matches the actual file data, via checksum so filenames aren't required to be the same right?), how does the dedup work, can you be selective of what version to keep or am I misunderstanding that the data presented to the user doesn't live at any of the locations on subvolumes, they're just references to the actual data elsewhere?

[polarathene]

I use BTRFS on my laptop and my servers for quite some time now and while it's not yet as idiot-proof as ext4 (balancing, fragmentation), it seems to be on a good track getting there.

I'd be interested in your experience/feedback on my previous post too if you don't mind I think with openSUSE default at install it's setup with /home as XFS to avoid the Downloads issue or affecting /home in snapshots/reverting, such that BTRFS is mostly used for keeping the core system in check/stable/reliable vs your personal data which would be a bit more unpredictable/messy in usage and should be backed up externally elsewhere?

[nanonyme]

Does this mean Fedora installer will finally be changed to allow /boot on Btrfs?

[nanonyme]

I'd be interested in your experience/feedback on my previous post too if you don't mind I think with openSUSE default at install it's setup with /home as XFS to avoid the Downloads issue or affecting /home in snapshots/reverting, such that BTRFS is mostly used for keeping the core system in check/stable/reliable vs your personal data which would be a bit more unpredictable/messy in usage and should be backed up externally elsewhere?

Why wouldn't you want rotating snapshots for /home? It's basically undelete mechanism for files that were included. Obviously these should be time-triggered and not installation-based. I have never heard about this "Downloads issue"