Live data from Hacker News

Who Needs Git When You Have ZFS?

zef.me

51–60 of 148 posts

Re: Who Needs Git When You Have ZFS?

#53
post #11
post #10

Earlier quoted context omitted.

Sounds great. Can you also duplicate versions of a database to coworkers on the same machine without much cost?

Yes, if they have ZFS too, it is basically snapshot, send & receive. Or you can clone it and rsync it to them. Do not try to snapshot a running database though. Before you execute the snapshot you should make sure everything is flushed to disk. For example with PostgreSQL you need to create a checkpoint before the snapshot, so you write: SELECT pg_start_backup('prepare_my_snapshot'); AND when the snapshot is done: SE…

If it is the same pool, you can just do a clone. Send/recv is completely unnecessary there.

As for flushing the database first, it is unnecessary as long as the database is ACID compliant. If you use MySQL, you will probably want to freeze and flush the database first to be absolutely certain of safety. DDL statements and a few minor other things in MySQL are known not to be ACID compliant.

Re: Who Needs Git When You Have ZFS?

#54
post #41
post #33

Earlier quoted context omitted.

It's too bad that VSS is unreliable. If I had a nickel for everytime one of my backups failed due to a VSS writer issue, I'd own Symantec AND EMC. This has been across Win2k/2003/2008. We've been using 2012 for the last year (yeah, old stodgy corporations move slowly), and I haven't seen the same number of errors, but we're also not doing as many client based backups either.

Have you guys thought about giving Windows ZFS volumes over iSCSI and then take ZFS snapshots? For example with SQL Server, it should be possible to talk to the SQL Writer Service and create a consistent database snapshot of a live SQL Server database with ZFS. When this snapshot is taken you can send & recv the diff to a remote backup server.

I believe that SoftNAS is able to do that when Windows is using Samba shares hosted on ZFS.

Re: Who Needs Git When You Have ZFS?

#55

> Who needs Git? > Notably missing is support for merging So, it's almost like a car except it's missing its wheels No, it's not like Git

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

Re: Who Needs Git When You Have ZFS?

#56
post #20

If you look past the attention-grabbing headline, this shows some pretty cool stuff with ZFS, using source versioning as an analogy to explain what would otherwise be quite abstract when it comes to filesystems. The only thing I knew about ZFS was the name, this helped me see some of its impressive features. Of course, I'll take reliability & stability over fancy features any day, but I'm glad there's active developm…

> I'll take reliability & stability over fancy features any day

That is why people use ZFS and OpenZFS, they are battle tested and very mature.

Re: Who Needs Git When You Have ZFS?

#58
post #42

Earlier quoted context omitted.

What does Oracle have to do with anything? This is FUD.

It is certainly not FUD, see https://www.eff.org/cases/oracle-v-google The point is, Oracle have decided to sue once over usage of something they bought and may do so again in the future.

Exactly.

The legal situation of Google's use of Java APIs was always a tiny bit murky, but it was super-clear-cut compared to the use of ZFS-on-Linux.

Re: Who Needs Git When You Have ZFS?

#59
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 may be easier to just perform an instance-level rollback.

One problem that didn't really occur to me before I became more ops-side was that administrators would want to heavily restrict / remove users' (read: developers and even other sysadmins) abilities to create snapshots in the first place. Why would you remove self-service temporary backups and avoid a lot of backup restoration requests? I didn't realize that other engineers could be careless and keep dozens or even hundreds of snapshots over time that gobble up expensive storage resources (SANs are not cheap regardless of manufacturer) and slow down I/O transactions over time. That was why so many of my customers deploying stuff like VMware Lab Manager and vCloud Director demanded the ability to remove access to snapshot features.

As a result of the typical usage where user abuse of a very powerful feature threw things for a loop, the typical organizational structure and siloization of these environments means that nowadays SAN-side LUN snapshots are used more often than from the VM layer (the same administrators that manage VMware environments typically have rights to the SANs). Using ZFS like this is a developer-side reaction to me, but duplication of trying to solve the same problem when technical solutions have existed and are viable is exasperating.

Post reply on HN