21–30 of 148 posts
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.
Except you'll lose all the data since you created the snapshot... You've been able to do this for years on Linux with LVM anyway.
Yes, but that's the point
You're right about LVM though
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.
Except you'll lose all the data since you created the snapshot... You've been able to do this for years on Linux with LVM anyway.
>You've been able to do this for years on Linux with LVM anyway.
What's the point of saying this in that tone? I could achieve the same goal in a number of different ways - that doesn't make any of those methods invalid because another one exists.
Earlier quoted context omitted.
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…
> 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?
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…
Somebody further down mentions art assets. Also potentially relevant are document repositories.
ZFS isn't very easy to use for a lay person, but that's really only a "Time Machine"-esque front-end away.
"Oracle's (previously Sun's) next-generation file system" That's why you need to stick with Git.
> 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
That and the rather obvious 'sudo' in front of all the commands. I mean, it's a cool tool; I use it on my NAS (particularly like the ECC mode instead of dumb RAID), but the git-equivalence aspect looks a little bit like a flamebait ;-)
zfs allow zef mount,create,destroy,snapshot,rollback,diff,clone,send,receive mypool/projects
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.
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.
Except you'll lose all the data since you created the snapshot... You've been able to do this for years on Linux with LVM anyway.
Also, the discussion is centered around ZFS, there's no reason to bring up LVM. Everyone knows there's many ways to skin this cat and it doesn't make anyone appear any smarter because they know of one way.