Announcement

Collapse
No announcement yet.

Ubuntu Developers Seem To Be Really Pursuing ZFS Root Partition Support On The Desktop

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • starshipeleven
    replied
    Originally posted by hybridchemistry View Post
    I'd like to think I'm somewhat educated about ZFS, but I'm still kind of puzzled as to why folks want to use it as a root file system, particularly with a single drive (as I assume most Desktop installs would use). Do the ZFS permissions, quotas, etc become all that useful to Desktop installs?
    Snapshots and volumes is the main functionality for that afaik. It's basically a "windows restore points" done right, allowing you to rollback your ssytem to a specific point in time.

    Ubuntu is deploying their own utility to do that https://blog.ubuntu.com/2018/10/15/d...-zfs-with-maas

    While OpenSUSE has Snapper for the same job on Btrfs.

    Leave a comment:


  • Buntolo
    replied
    Originally posted by jacob View Post

    Pretty much this. Upstream Linux developers should remind Canonical that the GPL matters and that the onus is on ZFS to comply with it, not the other way around. From a technical point of view ZFS makes me puke on a server; on a desktop the idea is downright repulsive IMO.
    Can you explain why?

    Leave a comment:


  • MrMorden
    replied
    Originally posted by hybridchemistry View Post
    I'd like to think I'm somewhat educated about ZFS, but I'm still kind of puzzled as to why folks want to use it as a root file system, particularly with a single drive (as I assume most Desktop installs would use). Do the ZFS permissions, quotas, etc become all that useful to Desktop installs?
    Snapshots are moderately useful (although you can get some of that capability with LVM); being able to quickly zfs send those snapshots to a file server and have them available forever is crazy useful.

    Leave a comment:


  • Chugworth
    replied
    Well it's interesting news for me. ZFS on Linux version 0.8 is looking to be pretty nice. I've lost faith in Btrfs, and Red Hat's answer to it is a big joke. Bcachefs does look hopeful, but how many more years until it becomes a trustworthy filesystem with features that compare to ZFS or Btrfs?

    ZFS gives some nice features. Obviously the snapshots are great, but the send and receive features are very nice as well. Or you could make backups from servers that aren't running ZFS by using rsync with the "--inplace" switch, then take a snapshot of it for ultimate space savings. Really cool stuff.

    Leave a comment:


  • k1e0x
    replied
    Originally posted by DoMiNeLa10 View Post
    Sounds like a call to boycott Canonical (and possibly sue them due to license breaches) to me. I hope they back down before they actually deface GNU GPL, because they're large enough to become a scapegoat. People posting publicly should back off and think again before publicly considering whether breaking GPL is a good idea (it's not).

    I hope Linux developers will wage a war against ZFS, as it will enforce the GNU GPL, and with enough pressure it might cause Oracle to re-license their file system under acceptable terms (not that I care about the file system).
    The hell?? lol

    It's not breaking the GPL anymore than your Nvidia driver. The difference is ZFS is actually open source.. Nvidia isn't. (you've no problem with that tho right?) And Oracle does not control the license to ZoL or OpenZFS.

    I'm glad Linux is moving forward and getting a terrific file system out to every day users. Good job! Data integrity for everyone! .. and it's about time.
    Last edited by k1e0x; 02-12-2019, 09:30 PM.

    Leave a comment:


  • Britoid
    replied
    Originally posted by DoMiNeLa10 View Post
    Sounds like a call to boycott Canonical (and possibly sue them due to license breaches) to me. I hope they back down before they actually deface GNU GPL, because they're large enough to become a scapegoat. People posting publicly should back off and think again before publicly considering whether breaking GPL is a good idea (it's not).

    I hope Linux developers will wage a war against ZFS, as it will enforce the GNU GPL, and with enough pressure it might cause Oracle to re-license their file system under acceptable terms (not that I care about the file system).
    Can the 5 people in the room that would actually do this please stand up.

    ZFS won't be re-licensed anytime soon.

    Leave a comment:


  • jacob
    replied
    Originally posted by DoMiNeLa10 View Post
    Sounds like a call to boycott Canonical (and possibly sue them due to license breaches) to me. I hope they back down before they actually deface GNU GPL, because they're large enough to become a scapegoat. People posting publicly should back off and think again before publicly considering whether breaking GPL is a good idea (it's not).

    I hope Linux developers will wage a war against ZFS, as it will enforce the GNU GPL, and with enough pressure it might cause Oracle to re-license their file system under acceptable terms (not that I care about the file system).
    Pretty much this. Upstream Linux developers should remind Canonical that the GPL matters and that the onus is on ZFS to comply with it, not the other way around. From a technical point of view ZFS makes me puke on a server; on a desktop the idea is downright repulsive IMO.

    Leave a comment:


  • DoMiNeLa10
    replied
    Sounds like a call to boycott Canonical (and possibly sue them due to license breaches) to me. I hope they back down before they actually deface GNU GPL, because they're large enough to become a scapegoat. People posting publicly should back off and think again before publicly considering whether breaking GPL is a good idea (it's not).

    I hope Linux developers will wage a war against ZFS, as it will enforce the GNU GPL, and with enough pressure it might cause Oracle to re-license their file system under acceptable terms (not that I care about the file system).

    Leave a comment:


  • mskarbek
    replied
    Originally posted by skeevy420 View Post
    You have to create restricted datasets by specifically disallowing ZFS features at pool creation for Grub to be able to read it.
    I know, that is why I mentioned the rewrite of ZFS code for the purpose of allowing Grub to access newer functionalities. I also know that there are situations where such support would be very helpful (to say the least) but the main focus of this article is a modern desktop environment where UEFI is basically a standard those days and you don't need systemd at all for that to work.

    Originally posted by skeevy420 View Post
    I'd like to be able to use SELinux user and group contexts on pools and datasets in general, not just on the files underneath them.
    What you are describing IMO fits better into zfs allow/unallow functionality as its extension rather then SELinux integration.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by mskarbek View Post

    There is no need to rework Grub (and that would mean massive rewrite of parts of the ZFS code base into Grub if you would like to boot from encrypted root dataset for example forced by CDDL) because you don't need Grub at all, UEFI solved that issue.
    What better integration with SELinux you have in mind?
    You have to create restricted datasets by specifically disallowing ZFS features at pool creation for Grub to be able to read it. The Arch Wiki has a decent write up on it. Not everything modern has UEFI and there is a lot of older, non-UEFI hardware that is better, more powerful, and more capable to leverage ZFS's strengths over certain modern UEFI systems so Grub with full ZFS support, on any other BIOS+UEFI bootloader for that matter, is almost necessary for a distribution to claim full ZFS support. Also, even though I am a systemd user, systemd-only solutions suck and shouldn't be encouraged.

    I'd like to be able to use SELinux user and group contexts on pools and datasets in general, not just on the files underneath them. Like if "zpool list" was ran as a regular user, only that user's dataset, like tank/home/$USERNAME, would show up and not tank/system/snapshots, tank/system/usr, or tank2onAnotherDiskForGrub/boot. Not everyone needs to know exact pool names, locations, etc. I'm not actually sure if that would be handled by SELinux, ZFS, or a little bit of both...hell, it might be possible now, been a while since I've looked into the two since I don't use SELinux on a regular basis nor am I usually bothered by security concerns...it's just something I've been thinking about since a discussion about multiseat Linux boxes the other day.

    Leave a comment:

Working...
X