Earlier quoted context omitted.
full time?? wow
One unknown person called Linus Torvalds is one of them ;).
And there was me thinking Mr Torvalds mostly provoked conflicts.. :p
Who Needs Git When You Have ZFS?
131–140 of 148 posts
Re: Who Needs Git When You Have ZFS?
#132Earlier quoted context omitted.
> Do not try to snapshot a running database though. Before you execute the snapshot you should make sure everything is flushed to disk. Is a database (or anything else) really supposed to behave that way? Shouldn't every state along the way be possible to resume from? In particular, shouldn't database transactions take care of this?
Yes, it is. One of the fundamental principles of practical RDBMS is durability (the D in https://en.wikipedia.org/wiki/ACID ), meaning that when the DB acknowledges a commit to the client, it must be guaranteed that the transaction has been reflected in permanent storage (i.e., on disk). The fine print: Due to the architecture of file system access in contemporary kernels (esp. file system caches), it's next to impos…
> The fine print: Due to the architecture of file system access in contemporary kernels (esp. file system caches), it's next to impossible for a user-space application to actually guarantee that writes are durable (i.e. synced to disk at a defined point in time), but most RDBMS manage well enough in practice.
While this doesn't relate to a specific file, you can always look at the size of Dirty and Writeback in /proc/meminfo. They correspond to the amount of dirty file page caches that have yet to be synced.
Re: Who Needs Git When You Have ZFS?
#133Earlier quoted context omitted.
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).
The object store is done in the way it's done for two reasons. The first being that using individual files doesn't require opening some database file to parse the state of the repo -- and pushes and pulls are very simple to implement (you just download the objects to .git/objects and then update any refs in .git/refs). Secondly, the splitting of the filename into a directory is because filesystems have very bad performance when you put >500000 files in one directory. Remember that git was created to deal with the Linux kernel source, so they have very large numbers of git objects and operations need to be fast.
I actually think the git object store is very clever. ;)
Re: Who Needs Git When You Have ZFS?
#134Earlier quoted context omitted.
Actually, the CDDL allows the person who wrote the License (Sun, now Oracle) to release a new version of the license that implicitly updates the license for all projects using the old license (It's like the "or any later version" thing with the GPL, but I'm fairly sure it's not optional with CDDL). Which is why people are asking why Oracle doesn't just release CDDL 2.0 that is GPL compatible.
New CDDL code outside of Oracle is under CDDLv1 only to prevent them from doing as they please with the license terms.
But ZFS is not under that other license (which might be called CDDLv1, but that's confusing). I don't get why new software uses the CDDL over the MPL if you want "file based copyleft". If you want copyleft, just use the GPL.
Re: Who Needs Git When You Have ZFS?
#135I personally feel that we should all hop off the ZFS (on Linux) hype train and consider a few points. Currently ZoL is being developed by two people, and it works by creating a translation layer into the Linux kernel API. The bug list is enormous (much bigger than btrfs), and there isn't enough experience with the codebase by Linux kernel developers. That's ignoring the potential legal issues. No other ZFS port has these problems.
On the other hand, if you want a supported filesystem with many of the same features as ZFS, there's btrfs. It alleviates all of the problems with the ZoL port. And there's no fear of Oracle lawsuits.
Re: Who Needs Git When You Have ZFS?
#136Earlier quoted context omitted.
I really don't think the article was seriously suggesting what you think it was; showing similarities between different types of tools (usually a more familiar one and a less familiar one) is meant to be illustrative
"I really don't think the article was seriously suggesting what you think it was" Then maybe it shouldn't have a purposefully click-baitingly title suggesting it does...
>> I really don't think the article was seriously suggesting what you think it was
> Then maybe it shouldn't have a purposefully click-baitingly title suggesting it does
I normally hate clickbait, and yet I liked this article and its headline. Maybe because the tone was self-deprecating, like me getting on a bicycle and saying, "Look out, Tour de France!"
Actually, it's like a fish getting on a bicycle and jokingly saying, "Look out, Tour de France." Maybe the fish isn't anywhere near good enough on a bike to compete in the Tour de France, but still, it's a fish on a bicycle.
In the same way, Git will run circles around ZFS as a source-code version-control system. On the other hand, it's way cool that ZFS can even do some of these things, because after all it's just a filesystem.
Re: Who Needs Git When You Have ZFS?
#137Earlier quoted context omitted.
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
I think its wise to have a healthy housekeeping policy if you're going to use lvm snapshots. Any point in time copy on write snapshot is going to cause performance degradation. However, it really depends on the volume and you can't speak universally for everything/everybody. For example if you have a drive with 100 files but only write to one of them. (for simplicity) The first time you rewrite those blocks are going to endure the hit for the copy on write. (dual writes) After that first rewrite of all those blocks you can't really tell the difference that the snapshot exists. This obviously assumes that you don't have a ton of additional snapshots compounding writes..
Re: Who Needs Git When You Have ZFS?
#138Earlier quoted context omitted.
> ZFS is excellent for database development! Create a snapshot before you try something that mess up your data and instantly restore it! If your development database is a few gigabytes, this will save you a lot of time. The proper way of doing this is to clone the snapshot and then spin up a new container using the clone. That way you do not need to risk downtime on your production code. I believe that Delphix has a…
> The proper way of doing this is to clone the snapshot Might not be really feasible. In order to create a consistent snapshot you have to stop the database server (or, if running a multi-master setup, take one master out of replication, but MM setups are rare and even more so is experience with them). Then, you have to actually do the clone - with a couple-GB-sized database, that's easy and fast but once you hit tri…
I think you are confused about ZFS clones. You never stop a production application for a clone because the clone is made from a snapshot. It also is copy on write, so you have no massive data copy. If your application, is not crash consistent, you do need to get it to pause, flush a consistent state and do the snapshot, but the snapshot takes less than a second to do, so such a thing is probably fine.
Also, if you need to stop the database for a consistent snapshot, then your database is not ACID compliant.
Re: Who Needs Git When You Have ZFS?
#139Strange there's no mention of FreeBSD's excellent ZFS implementation
Yes, and the article casually implies that ZFS totally works not only on Linux but also on OS X[1], which is... a stretch.
I check on it every year or so, but my impression is that ZFS on Mac is still so far behind where ZFS is on FreeBSD and (more recently) Linux, that it isn't really clear whether ZFS will ever work reasonably on the Mac.
(I would love to hear experiences of people actually using it on OS X, though! I may be out of date.)
Re: Who Needs Git When You Have ZFS?
#140Earlier quoted context omitted.
> 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,…
The CDDL's restriction is only in the files containing the code. The GPL's restriction is on all files within a derived work, whether they contain GPL code or not.