SoylentNews is people
SoylentNews
from the bazaar?-what-bazaar?-this-is-my-cathedral dept.
In the release notes for RedHat Enterprise Linux 7.4 we can see the following:
The Btrfs file system has been in Technology Preview state since the initial release of Red Hat Enterprise Linux 6. Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux.
The Btrfs file system did receive numerous updates from the upstream in Red Hat Enterprise Linux 7.4 and will remain available in the Red Hat Enterprise Linux 7 series. However, this is the last planned update to this feature.
Red Hat will continue to invest in future technologies to address the use cases of our customers, specifically those related to snapshots, compression, NVRAM, and ease of use. We encourage feedback through your Red Hat representative on features and requirements you have for file systems and storage technology.
Btrfs, originally developed by Oracle and now also by SUSE and others, seems to have lost Red Hat as supporter. So what is ahead? RH isn't very clear. ZFS had license issues since day one, and is currently under Oracle umbrella, making a change near impossible. Does this mean improving XFS? Some other FS to be announce soon? Will Red Hat push its weight around like in other cases? Will other distros hold their ground or bow? Unix wars all over again, this time in Linux and FOSS land.
Maybe time to update it to Corporate Open Source Software, COSS, you can look but forget about having a voice among the big guys. The bazaar is dead, long live the cathedral. Or time to fork them off.
(Score: 2) by Entropy on Thursday August 03 2017, @12:25AM (3 children)
BTRFS is an inferior version of ZFS, basically. The interface is awful in comparison, and it has many silly requirements(why exactly would I want snapshots mounted all the time or read-write? Kinda defeats the point.) Also why is a snapshot command like a copy command?
btrfs subvolume snapshot /mnt/data /mnt/data_mysnap
vs
zfs create mnt/data@mysnap
Which is more intuitive? A snapshot isn't a COPY. It never was a copy. It's a set of pointers moved around. In BTRFS I furthermore have to worry about some program bumbling into my snapshot and changing something because it's both obviously mounted, and writeable. BTRFS to my knowledge has never had volume support(like devices).
Keep in mind with ZFS's volume support comes snapshot of volumes(think virtual machines) and block-level replication of those virtual machines.
(Score: 2) by sjames on Friday August 04 2017, @01:13AM (2 children)
You can mark the snapshot read only if you like. the fs doesn't treat it as distinct from a COW duplicate because it has no need to. You may make it read only and treat it as special if you want, it's an administrative policy.
The snapshot/copy isn't really mounted all the time, think of the root volume of a btrfs as the administrative interface. You can unmount that when not operating on the filesystem, or put it where only root can see it. use the subvolid option to mount to directly mount the subvolumes without exposing the root volume with the snapshots in it.
You are correct about volume support. It would be nice for BTRFS to get that at some point.
(Score: 2) by Entropy on Friday August 04 2017, @01:19AM (1 child)
You can work around it... It's just always felt more clumsy to me than ZFS. Seeing as ZFS came first, and has wide enterprise support I wish they just stole the interface. As to not mounted all the time, I think if you find / ...it'll list all the files. Can you truly make it not mounted as in it isn't in the directory tree anywhere?
(Score: 2) by sjames on Friday August 04 2017, @01:54AM
Yes. By convention, you create a subvolume called @ and mount it to /. You may also create things like @home or (depending on need, @username) and mount it all up using the subvolid option.
I typically ALSO choose to mount the root as /btrfs with root owning the mount point and only root granted access, but that is purely optional and a matter of taste. This means that /btrfs/@ is the same as /. Skip that and it's not in the tree.