Author is not actually suggesting replacing your version control with ZFS. From the first paragraph: > Of course, I'm not seriously suggesting you'd ditch a "proper" version control system, but it gives a good sense of what's possible at the file system level.
So the title is click-bait, then? I almost read the article, but in the 342 milliseconds between thinking that and reaching for the mouse, I came up with three reasons the topic alluded to in the title would be a dumb idea. And it turns out that's not what the article is about anyway.
Good work, you avoided learning a thing! :hooray emoji:
Author is not actually suggesting replacing your version control with ZFS. From the first paragraph: > Of course, I'm not seriously suggesting you'd ditch a "proper" version control system, but it gives a good sense of what's possible at the file system level.
I like how he uses of course . "Of course," the title of this article is misleading. The article is about something different, but this was the most clicky baity combination of words including "git" and "zfs."
Clickbait? Yes. Interesting article? also yes. The problem with clickbait is it's often used to bait you into reading BAD content or content irrelevant to your interests. Clickbait + good/related content is just clever marketing.
Anyone here think that a "ZFS in the cloud" that anyone could inexpensively export a ZFS snapshot (or volume) to would potentially be a business model (offsite backups, etc.)?
Three year old article teaches slightly outdated techniques and basic ZFS usage on linux by way of specious comparisons to GIT. I guess it wasn’t a half bad resource when it came out, but these days there’s got to be better blog posts about this, right? EDIT: Not that I’m bitter; I love zfs. I mainly wonder how something so old ended up here.
I very much appreciated this article and shared it with coworkers who also found it helpful. I can understand the desire to only read the latest news, but I've learned a lot of stuff in my life that was useful but only new to me. The key benefit to this article was the comparison of ZFS to something I am familiar with: Git. My wild guess is that other non-filesystem geeks like me liked this article for similar reasons and upvoted despite its age.
Edit: Perhaps the ZFS to Git comparison is itself novel? I would like to read about other filesystem features (any file system) from this perspective because I think I would learn a lot.
I don't get how the word "incompatible" can be understood as anything other than both license has aspects which makes combining them impossible. But owell, lets see what the license text actually say: Any Covered Software that You distribute or otherwise make available in Executable form must also be made available in Source Code form and that Source Code form must be distributed only under the terms of this License.…
> If we were to make an identical copy of the CDDL license and call it CDDLv2, those two identical twins would be incompatible with each other. Software under CDDLv1 would not be permitted to be combined with software under CDDLv2 and distributed as source code. There is a CDDL v1.1 that is effectively 's/Sun/Oracle/'. The CDDL has an optional clause saying any later version is allowed and the CDDL only applies at th…
Okey, correction then, if you are not Sun/Oracle (and most people aren't) and create an identical copy of CDDL and call it "bobs license", then BL and CDDL is incompatible because of the conditions in the otherwise identical licenses. Point being, the condition that create the incompatibility between CDDL and GPL is that both want their license to be used when distributing. Remove that condition from either license, that is CDDL or GPL, and the license incompatibility goes away. It would also turn either license into a permissive license.
> Notably missing is support for merging, which ZFS does not have direct support for as far as I'm aware. So, no replacement. Merge and Branch are the major features of git. The bigger the project the bigger the need for these. I know some projects where people work full time as merge conflict resolvers. Without git that would require a whole team instead of a person.
ZFS could not be a replacement for all of git, but (if you wanted to) you could use it to replace git's storage layer, which is basically independent of operations like merge. I.e. you can git-merge ZFS subvolumes (without any actual git repos) with recursive git-merge-file.
That is a very interesting idea, imo. I don't really like the object storage backend. E.g., I'm not sure if it's really the smartest to split the hash into directories and filenames. And the whole idea of tree files seems flawed (you don't need them if you consider the (checked out) file path as part of the file name and have that completely in commit files as if they would be a single global tree file).
> Notably missing is support for merging, which ZFS does not have direct support for as far as I'm aware. So, no replacement. Merge and Branch are the major features of git. The bigger the project the bigger the need for these. I know some projects where people work full time as merge conflict resolvers. Without git that would require a whole team instead of a person.
"Of course, I'm not seriously suggesting you'd ditch a 'proper' version control system, but it gives a good sense of what's possible at the file system level."
That's what the title says in big letters at the top though.
True, but you can/could easily do that with LVM snapshots and merges too. We snapshot the databases (copy on write) which is instant, then if we want to roll it back we lvm merge and remount. Everything is pretty instant and it doesn't matter what filesystem you want to use.
Do LVM snapshots still cause massive performance degradation? https://www.nikhef.nl/~dennisvd/lvmcrap.html
Depends. Thick provisioned (conventional) LV snapshots take a hit. Thin provisioned LV snapshots take a much smaller hit, almost negligible.
Are there any beginner resources for learning about file systems? Would be smart / harmful to reformat my whole macbook ssd to ZFS?
I don't think you can use ZFS as a boot volume on Macs (and only on Linux with caveats).
The limiting factor is the bootloader. Mac firmware can read HFS+ natively, find the bootloader, which in turn recognizes HFSX, Apple RAID, and Apple Core Storage. I doubt any of the previous ZFS support exists in the current bootloader.
Unlike linux where there's a separate /boot, OS X doesn't really separate boot from root file systems. So how you'd boot XNU from HFS+ and transition to a separate ZFS root fs isn't obvious to me from the existing documentation.
I've been working with virtual machines in production and development for well over a decade now and a lot of what works via ZFS in this article works very similarly to how it would work we used AWS or VMware style snapshots. In fact, ZFS snapshots are only so helpful if you make complicated changes across multiple ZFS volumes, for example, that require some more transactional style rollbacks. In such scenarios, it m…
VMware snapshots are NOT like ZFS snapshots. VMWare snapshots are extremely heavy an will have massive performance impact if left around for an extended period of time for any I/O sensitive VM. ZFS snapshots are essentially 0-overhead from a performance perspective, and function in a very different manner.