17 ms·

Who Needs Git When You Got ZFS? (2013)

143 points by matt42 12y ago

mrb 12y ago
$ dd if=/dev/zero of=/tmp/disk1.img bs=1024 count=10485760 is a terribly inefficient way of creating a test image. It wastes 10GB of disk space. It takes dozen of seconds to run. Etc. Instead you can create a sparse file of 10GB that takes 0 bytes on disk. The creation of such a file is instantaneous: $ dd if=/dev/zero of=/tmp/disk1.img bs=1024 seek=10485760 count=0 The key is seek=XXX. The filesystem will not allocate blocks before this offset. An application reading before this offset will just read virtual zero bytes. Otherwise, this is a nice succinct article showcasing the snapshot/clone feature and send/receive snapshot deltas between 2 systems. Edit: on Mac OS X, UFS supports sparse file, but not HFS+. On Linux, all major fs support sparse files.
- LeoPanthera 12y ago
  Huh. I didn't know that. Does it work on any filesystem?
  - bashinator 12y ago
    I believe the filesystem needs "sparse file" support.
  - panzi 12y ago
    I think about anything newer than fat32 supports sparse files.
    - deleted 12y ago
      [deleted]
    - dasmoth 12y ago
      The FS people today are likely to come across which doesn't support them is HFS+.
      - e12e 12y ago
        Afaik neither exFat or fat32 support it -- and they are still(?) popular for flash sticks and/or drives that needs to be shared between OS'.
- misframer 12y ago
  $ truncate -s 10485760 /tmp/disk1.img is another way of doing it.
- awda 12y ago
  The bad part is bs=1024. That block size will make it take longer. Often, a sparse file doesn't really emulate a real file well, and you do want a big file full of zeroes...
  - crest 12y ago
    Not on a copy on write file system.
    - awda 12y ago
      What does CoW have to do with anything?
- khc 12y ago
  Unless you want the space to be pre-allocated
  - stevekemp 12y ago
    Yeah I've seen hosting companies in the past use sparse files for virtual machine storage - all is good unless, or until, they overcommit. At which point you have filesystem-soup..
  - anon4 12y ago
    Yes, the better way is by using the fallocate program which uses the posix_fallocate syscall, which makes a new file with a given size containing whatever happened to be on disk at the time. Basically malloc for filesystems.
- deleted 12y ago
  [deleted]
mantrax5 12y ago
> "Using ZFS as a replacement of Git for is probably not a good idea." Uhm. > "I’m not sure of the stability on Mac at this time. Using ZFS as a root file system on Linux is still slightly problematic at this moment." And Windows? Never mind. Ok, so the author wrote an article called "Who Needs Git When you Got ZFS", and then in the body of the article the conclusion is more like "Who needs ZFS When You Got Git". ZFS does a bunch of cool stuff in a generic way as a file system, sure. But we already have apps doing it better in a way specific to real-world needs (i.e. Git), on more platforms, and I don't have to fear if I'll corrupt my boot volume if Git is buggy.
- mrb 12y ago
  In reply to your (edited out) comment that "ZFS saw poor adoption": You might not know it, but out of all the new filesystems designed after 2005 (a few dozens?), ZFS appears to be the one that has seen the fastest adoption/growth [1]. Source: my anecdotal experience in the industry, the experience of many of my colleagues, random consultants reporting "I've seen 1000's of large ZFS deployments" [2], etc. [1] Outside of ext4 which was introduced in 2006 and was a simple refresh of ext3, not really a "new" filesystem. [2] http://nex7.blogspot.com/2013/03/readme1st.html http://nex7.blogspot.com/2013/03/readme1st.html
  - hdevalence 12y ago
    Note that ZFS began development in 2001, not 2005, so ZFS itself isn't a new filesystem designed after 2005. The ZFS source code was first released in 2005, but it was announced a year prior. In any case, ZFS is actually somewhat older. To turn your question around: what new serious [1] filesystems have been designed since 2005 (or 2001) at all, regardless of adoption? I think that the answer is actually far less than a few dozen. I can think of four: ext4 (as mentioned), F2FS (announced 2012, started ?), btrfs (started 2007), and ZFS (2001). Maybe there are others, I don't know, but I don't really think there are even that many contenders for adoption. (If there are, I'd be interested to find out). [1]: By serious I mean in a sense similar to what is outlined here: http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdWhyItWon http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdWhyItWo... in particular "In specific, none of these alternate init systems did the hard work to actually become a replacement init system for anything much", but for filesystems instead of init systems. For example, I would not consider HAMMER to be a 'serious filesystem' for the purposes of this list, whatever its technical merits.
jimmcslim 12y ago
Given the article is from August 2013 does anyone have any updated feedback on the stability of ZEVO's ZFS-for-Mac product? I'm using ZFS quite happily on a HP Microserver (although I have yet to have to recover from any disk failures, and do weekly automated scrubs) and would consider using it on my Mac.
- runlevel1 12y ago
  ZEVO doesn't currently work in OSX 10.9. Despite its name, ZEVO Community Edition is a closed source project run by GreenBytes (recently acquired by Oracle). Back in Nov. 2013, GreenBytes announced that they don't have plans to continue development of ZEVO.[^1] So unfortunately, ZEVO is dead project. [^1]: http://zevo.getgreenbytes.com/forum/viewtopic.php?f=5&t=2244 http://zevo.getgreenbytes.com/forum/viewtopic.php?f=5&t=2244
  - anders 12y ago
    ZFS on OS X has been picked up by a new project: https://openzfsonosx.org/ https://openzfsonosx.org/
jrockway 12y ago
Let me know when I can host my project on zfshub.com.
- croggle 12y ago
  "Using ZFS as a replacement of Git for is probably not a good idea" That's from the article... You know... that thing you didn't read? I don't know what the correct term is for the kind of title here but it's not supposed to be literal. EDIT: title is tongue in cheek.. maybe even linkbait but in a clever way rather than a negative way.
  - cryptonector 12y ago
    Yeah, but the title is still interesting on its own.
- mst 12y ago
  This isn't slashdot, John. If you're going to be a sarcastic dick for no good reason, you at least have to be able to pretend you read the article first.
  - pessimizer 12y ago
    I'm sure he feels terrible, Matt.
    - jrockway 12y ago
      Only because he misspelled my name.
- zupa-hu 12y ago
  oh guys, you have so much humor! (speaking FOR the comment) I in fact started actually reading the article only to be let down that it is not about an alternative to git. Remember the times when there was a correlation? Welcome to the tricking-each-other-into-reading-stuff age. I want to keep the right to believe that an article is a long version of the title, thus keep the right to comment on the idea held in the title as if it was the content. Don't forget that there could always be a longer version. And considering the title only, the comment does have its place. Now go downvote me too.
transfire 12y ago
While what the author demonstrates as the capabilities of ZFS to act in many respects like a version control system --one that you would never actually use, I think is foretells a future for file systems. It only makes sense that versioning should in fact become a standard part of all file systems eventually. There are definite limitations born of version control and file system not "living in the same world", so to speak. The most obvious of these is the notorious `rm foo`, oops... I mean `git rm foo`!
- JadeNB 12y ago
  Not just future, I think: http://en.wikipedia.org/wiki/Versioning_file_system#Implementations http://en.wikipedia.org/wiki/Versioning_file_system#Implemen....
- GFK_of_xmaspast 12y ago
  I was using a versioned file system in 1992, and you didn't even have to be a privileged user to take advantage of it.
  - snogglethorpe 12y ago
    ... and versioned file systems in production use have been around since at least the early '70s... (tenex/twenex, etc)
    - wglb 12y ago
      and Tops10, Tops20 as well.
  - mst 12y ago
    I've never met anybody who described being any sort of VMS user as privilege.
    - VLM 12y ago
      Could have been using AFS over the network, I was using that in '92 right up to today, at least using it at home. AFS snapshots are no big deal today, but I don't remember using them or not in '92.
jackyb 12y ago
One thing that Git does not do is to track files, for a good reason. Git was designed primarily to track content which means it can track code movement between files and be smarter about compression. It is not limited by architecture of a file system.
- dsturnbull2049 12y ago
  ZFS is not limited to your concept of a file system either. Any change is represented by the addition of a series of one or more blocks, which can be seen as direct equivalents to blobs in git. ZFS is copy-on-write, so you can always reference any particular content change regardless of what file it was called when you made it. Compression and deduplication are handled almost the exact same way as you'd expect.
amckinlay 12y ago
We need some way for these snapshotting/logging file systems to integrate with application-level versioning to reduce duplication. I had this problem with git and nilfs2.
- rakoo 12y ago
  As far as I know, ZFS does "automatic" deduplication, meaning that your application doesn't have to care about specifying it to the filesystem; ZFS will automatically detect duplicate regions and store them only once.
  - chousuke 12y ago
    ZFS can do dedup if you enable it, but IIRC the recommended amount of memory to safely use it is ~5GB per terabyte of storage.
seryoiupfurds 12y ago
Something similar is done for Plan 9 development using the Fossil+Venti filesystems. You need access to the Fossil fileserver console to force a snapshot ``right now'' rather than waiting for the next scheduled time, but since Fossil is a user-space program, you could trivially run your own separate Fossil filesystem against the Venti store without needing any sort of root access.
- 4ad 12y ago
  Not only fossil+venti, the old standalone cached-worm file server, and its user-space port cwfs were also built around versioning. By default, the cached-worm systems are dumped at 5am every day in the morning, meaning you can access your files as they were at 5am every day. You can manually dump them whenever you please, of course. These dumps are cheap, but not as cheap as fossil or ZFS (or git) snapshots. Unlike ZFS (not sure about git), these dumps are immutable, you can't delete them. With fossil+venti, you still get daily dumps, but you also get finer grained ephemeral snapshots. By default at 15 minute intervals, I used to set them at 5 minutes. You can control how long you want to keep these in fossil, I kept mine for 3 months. The dumps are venti are immutable. These are very very cheap, and these systems also do deduplication, by default. I don't run fossil anymore, I like the features, but reliability was less than stellar for some people, and the performance is much lower than cwfs, which is what I use now. Cwfs is very fast, rock solid, and very easy to recover in case of a catastrophe. I miss ephemeral snapshots, but cwfs dumps are cheap enough I can run them for what in a normal system you'd do "commits" for. I miss all these features when I am forced to use Unix. Git does two things, history preservation and patch management. For history preservation, nothing beats the Plan 9 system. What git does better is patch management. I think it's valuable not to conflate these two concepts and create tools that can solve each one well, and work well together.
frik 12y ago
We should think more out of the box. BeOS BFS, (ReiserFS4) and early versions of NTFS supported extensive object oriented metadata and search capabilities ("Cairo") - something like WinFS but directly in the filesystem driver. Data could be organized like in relational databases today, you could find your data in various ways. Not just in the old and proven way of hierarchical directory tree. A modern filesystem that is available for common operating systems would be a good starting point. I am not sure if ZFS is the answer, there might be better FS around, but we need definitely rock-solid file system drivers that we can rely on for WinNT 5+ and current OSX (as well as Linux and *BSD but at least ZFS has it for the later). At the moment the common determinator of all filesystem drivers are various editions of Microsoft FAT filesystem - a pretty basic and old filesystem by today's standards. NTFS as filesystem is very rock-solid and read & often also write support is available in all common OS. We would definitely benefit if solid r/w filesystem drivers like ext4, XFS, ReFS, BFS/BeFS, Btrfs, etc. would be available on more OS platforms.
- sdrinf 12y ago
  | We should think more out of the box. BeOS BFS, (ReiserFS4) and early versions of NTFS supported extensive object oriented metadata and search capabilities ("Cairo") - something like WinFS but directly in the filesystem driver. Data could be organized like in relational databases today, you could find your data in various ways. Not just in the old and proven way of hierarchical directory tree. The second you open that up to application layers, you are facing a wide range of problems. Specifically: * Common schema: each application considers itself a unique snowflake, and might want to use different columns to mean different sort of things. We've been here before -semantic web, RDF, etc- and the correct solution was letting the apps just manage their own database of stuff. * Selfish apps: There is nothing stopping apps from overwriting, or manipulating meta-info in ways that are detrimental to user experience. Consider the current case of "Set <x> as default browser", "Set <x> as default media player" at each launch, then multiply it across every schema column * Interop: Beos attempted to solve this by dumping meta-info into the archives. The problem is, when a file gets outside the original system/OS, these attributes will get truncated. Any workaround on this would require full agreement on changing all of the file transfer protocols, and storage methods on all OS. Also note, that the 90% of the case (localizing files instantly on multi-terabyte consumer-drives) is handled already via Windows Search & Finder. Personal experience on this shows, that you can safely drop the hierarchical madness in favor of filename-based search for most media/music/document cases; and there are ways you can apply this for development as well.
pan69 12y ago
I was actually interested in running a ZFS set up but after talking to some people they advised me not to run ZFS on a system without ECC memory. Reason being, if corrupt memory would be written into your ZFS set up you won't be able to recover from it. I'm curious about any further thoughts/experience on this.
- ossreality 12y ago
  how is that unique to zfs?
- thecabinet 12y ago
  One of you missed the point. The reason ECC is suggested with ZFS is because all of the other features (RAIDZ and checksumming in particular) don't do any good if your data gets corrupted in memory. This is true for all filesystems, but most of them don't try as hard to protect your data in the first place.
  - pan69 12y ago
    I could very well have got it wrong but the way I understand it was that in a file system such as ext4, if a file is somehow corrupted in memory and written to disk you might not be able to recover from this and the file might become useless. However, with ZFS you would lose "all" your files in the file system. Again, I might have misunderstood.
    - Elhana 12y ago
      Example of non-ecc memory corruption and effect: http://comments.gmane.org/gmane.os.illumos.zfs/1779 http://comments.gmane.org/gmane.os.illumos.zfs/1779
    - makomk 12y ago
      Wouldn't surprise me, ZFS is pretty bad at recovering from metadata corruption.
      - 12y ago
yamadapc 12y ago
As the article seems to be down, here's the text-only (google) cached version: http://webcache.googleusercontent.com/search?q=cache:CTMc7ZQuOB4J:zef.me/6023/who-needs-git-when-you-got-zfs&strip=1 http://webcache.googleusercontent.com/search?q=cache:CTMc7ZQ...
cryptonector 12y ago
git is not reliable in the face of power failures. I believe this is due to insufficient care taken in writing to reflogs and packs when receiving. (Reflogs are appended to, for example, while objects are first written to, fsync'ed, then renamed into place, so object writing is incrementally atomic, while everything else... not so much.) Fossil uses SQLite3, but it doesn't do what I want -- only git gives me the power of the index, rebase, and light-weight branches. (OK, Mercurial has those too, but it's too late and it sucks. Sorry.) Fossil does get several important things from using SQLite3: SQL for history (do NOT underestimate this), extensibility (one file format, trivially extensible schema), well-tested ACID semantics support. Oh, one more thing: using SQLite3 minimizes fsyncs per-transaction. There's probably more benefits, actually. And ZFS? Well, ZFS snapshots give you ACID. If you have a persistent ZIL then fsync() gives you barriers (nice!). But a) snapshots are slow by comparison to SQLite3 COMMITs, and b) you don't get the benefit of SQL. Oh: and not everyone can haz ZFS, but everyone can haz git. Everyone also can has SQLite3. My proposal: backend git's I/O abstraction layer (which is pretty nice) with SQLite3. And if you have ZFS, then always take a snapshot in a post-receive hook; destroy older snapshots later in a cronjob. (As for zfs destroy, you really want the async zfs destroy feature, which IIRC not every implementation has!)
- cryptonector 12y ago
  I'd really like reflogs and branches to themselves be objects. Only packs (maybe) and tags (also maybe) should not be objects. If reflogs were objects then... they could be pushed and pulled, which would be really nice indeed. If branches were objects then they could record rebase history. I would really like to be able to capture rebase history: what a branch's HEAD was before and after a rebase, as well as the picks/squashes/edits/rewords/drops done in an interactive rebase, and even the merge pre-/post-base (--onto).
songco 12y ago
Where is github for zfs?

143 points by matt42 12y ago

mrb 12y ago

$ dd if=/dev/zero of=/tmp/disk1.img bs=1024 count=10485760 is a terribly inefficient way of creating a test image. It wastes 10GB of disk space. It takes dozen of seconds to run. Etc. Instead you can create a sparse file of 10GB that takes 0 bytes on disk. The creation of such a file is instantaneous: $ dd if=/dev/zero of=/tmp/disk1.img bs=1024 seek=10485760 count=0 The key is seek=XXX. The filesystem will not allocate blocks before this offset. An application reading before this offset will just read virtual zero bytes. Otherwise, this is a nice succinct article showcasing the snapshot/clone feature and send/receive snapshot deltas between 2 systems. Edit: on Mac OS X, UFS supports sparse file, but not HFS+. On Linux, all major fs support sparse files.

LeoPanthera 12y ago
Huh. I didn't know that. Does it work on any filesystem?
- bashinator 12y ago
  I believe the filesystem needs "sparse file" support.
- panzi 12y ago
  I think about anything newer than fat32 supports sparse files.
  - deleted 12y ago
    [deleted]
  - dasmoth 12y ago
    The FS people today are likely to come across which doesn't support them is HFS+.
    - e12e 12y ago
      Afaik neither exFat or fat32 support it -- and they are still(?) popular for flash sticks and/or drives that needs to be shared between OS'.
misframer 12y ago
$ truncate -s 10485760 /tmp/disk1.img is another way of doing it.
awda 12y ago
The bad part is bs=1024. That block size will make it take longer. Often, a sparse file doesn't really emulate a real file well, and you do want a big file full of zeroes...
- crest 12y ago
  Not on a copy on write file system.
  - awda 12y ago
    What does CoW have to do with anything?
khc 12y ago
Unless you want the space to be pre-allocated
- stevekemp 12y ago
  Yeah I've seen hosting companies in the past use sparse files for virtual machine storage - all is good unless, or until, they overcommit. At which point you have filesystem-soup..
- anon4 12y ago
  Yes, the better way is by using the fallocate program which uses the posix_fallocate syscall, which makes a new file with a given size containing whatever happened to be on disk at the time. Basically malloc for filesystems.
deleted 12y ago
[deleted]

mantrax5 12y ago

> "Using ZFS as a replacement of Git for is probably not a good idea." Uhm. > "I’m not sure of the stability on Mac at this time. Using ZFS as a root file system on Linux is still slightly problematic at this moment." And Windows? Never mind. Ok, so the author wrote an article called "Who Needs Git When you Got ZFS", and then in the body of the article the conclusion is more like "Who needs ZFS When You Got Git". ZFS does a bunch of cool stuff in a generic way as a file system, sure. But we already have apps doing it better in a way specific to real-world needs (i.e. Git), on more platforms, and I don't have to fear if I'll corrupt my boot volume if Git is buggy.

mrb 12y ago
In reply to your (edited out) comment that "ZFS saw poor adoption": You might not know it, but out of all the new filesystems designed after 2005 (a few dozens?), ZFS appears to be the one that has seen the fastest adoption/growth [1]. Source: my anecdotal experience in the industry, the experience of many of my colleagues, random consultants reporting "I've seen 1000's of large ZFS deployments" [2], etc. [1] Outside of ext4 which was introduced in 2006 and was a simple refresh of ext3, not really a "new" filesystem. [2] http://nex7.blogspot.com/2013/03/readme1st.html http://nex7.blogspot.com/2013/03/readme1st.html
- hdevalence 12y ago
  Note that ZFS began development in 2001, not 2005, so ZFS itself isn't a new filesystem designed after 2005. The ZFS source code was first released in 2005, but it was announced a year prior. In any case, ZFS is actually somewhat older. To turn your question around: what new serious [1] filesystems have been designed since 2005 (or 2001) at all, regardless of adoption? I think that the answer is actually far less than a few dozen. I can think of four: ext4 (as mentioned), F2FS (announced 2012, started ?), btrfs (started 2007), and ZFS (2001). Maybe there are others, I don't know, but I don't really think there are even that many contenders for adoption. (If there are, I'd be interested to find out). [1]: By serious I mean in a sense similar to what is outlined here: http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdWhyItWon http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdWhyItWo... in particular "In specific, none of these alternate init systems did the hard work to actually become a replacement init system for anything much", but for filesystems instead of init systems. For example, I would not consider HAMMER to be a 'serious filesystem' for the purposes of this list, whatever its technical merits.

jimmcslim 12y ago

Given the article is from August 2013 does anyone have any updated feedback on the stability of ZEVO's ZFS-for-Mac product? I'm using ZFS quite happily on a HP Microserver (although I have yet to have to recover from any disk failures, and do weekly automated scrubs) and would consider using it on my Mac.

runlevel1 12y ago
ZEVO doesn't currently work in OSX 10.9. Despite its name, ZEVO Community Edition is a closed source project run by GreenBytes (recently acquired by Oracle). Back in Nov. 2013, GreenBytes announced that they don't have plans to continue development of ZEVO.[^1] So unfortunately, ZEVO is dead project. [^1]: http://zevo.getgreenbytes.com/forum/viewtopic.php?f=5&t=2244 http://zevo.getgreenbytes.com/forum/viewtopic.php?f=5&t=2244
- anders 12y ago
  ZFS on OS X has been picked up by a new project: https://openzfsonosx.org/ https://openzfsonosx.org/

jrockway 12y ago

Let me know when I can host my project on zfshub.com.

croggle 12y ago
"Using ZFS as a replacement of Git for is probably not a good idea" That's from the article... You know... that thing you didn't read? I don't know what the correct term is for the kind of title here but it's not supposed to be literal. EDIT: title is tongue in cheek.. maybe even linkbait but in a clever way rather than a negative way.
- cryptonector 12y ago
  Yeah, but the title is still interesting on its own.
mst 12y ago
This isn't slashdot, John. If you're going to be a sarcastic dick for no good reason, you at least have to be able to pretend you read the article first.
- pessimizer 12y ago
  I'm sure he feels terrible, Matt.
  - jrockway 12y ago
    Only because he misspelled my name.
zupa-hu 12y ago
oh guys, you have so much humor! (speaking FOR the comment) I in fact started actually reading the article only to be let down that it is not about an alternative to git. Remember the times when there was a correlation? Welcome to the tricking-each-other-into-reading-stuff age. I want to keep the right to believe that an article is a long version of the title, thus keep the right to comment on the idea held in the title as if it was the content. Don't forget that there could always be a longer version. And considering the title only, the comment does have its place. Now go downvote me too.

transfire 12y ago

While what the author demonstrates as the capabilities of ZFS to act in many respects like a version control system --one that you would never actually use, I think is foretells a future for file systems. It only makes sense that versioning should in fact become a standard part of all file systems eventually. There are definite limitations born of version control and file system not "living in the same world", so to speak. The most obvious of these is the notorious `rm foo`, oops... I mean `git rm foo`!

JadeNB 12y ago
Not just future, I think: http://en.wikipedia.org/wiki/Versioning_file_system#Implementations http://en.wikipedia.org/wiki/Versioning_file_system#Implemen....
GFK_of_xmaspast 12y ago
I was using a versioned file system in 1992, and you didn't even have to be a privileged user to take advantage of it.
- snogglethorpe 12y ago
  ... and versioned file systems in production use have been around since at least the early '70s... (tenex/twenex, etc)
  - wglb 12y ago
    and Tops10, Tops20 as well.
- mst 12y ago
  I've never met anybody who described being any sort of VMS user as privilege.
  - VLM 12y ago
    Could have been using AFS over the network, I was using that in '92 right up to today, at least using it at home. AFS snapshots are no big deal today, but I don't remember using them or not in '92.

jackyb 12y ago

One thing that Git does not do is to track files, for a good reason. Git was designed primarily to track content which means it can track code movement between files and be smarter about compression. It is not limited by architecture of a file system.

dsturnbull2049 12y ago
ZFS is not limited to your concept of a file system either. Any change is represented by the addition of a series of one or more blocks, which can be seen as direct equivalents to blobs in git. ZFS is copy-on-write, so you can always reference any particular content change regardless of what file it was called when you made it. Compression and deduplication are handled almost the exact same way as you'd expect.

amckinlay 12y ago

We need some way for these snapshotting/logging file systems to integrate with application-level versioning to reduce duplication. I had this problem with git and nilfs2.

rakoo 12y ago
As far as I know, ZFS does "automatic" deduplication, meaning that your application doesn't have to care about specifying it to the filesystem; ZFS will automatically detect duplicate regions and store them only once.
- chousuke 12y ago
  ZFS can do dedup if you enable it, but IIRC the recommended amount of memory to safely use it is ~5GB per terabyte of storage.

seryoiupfurds 12y ago

Something similar is done for Plan 9 development using the Fossil+Venti filesystems. You need access to the Fossil fileserver console to force a snapshot ``right now'' rather than waiting for the next scheduled time, but since Fossil is a user-space program, you could trivially run your own separate Fossil filesystem against the Venti store without needing any sort of root access.

4ad 12y ago
Not only fossil+venti, the old standalone cached-worm file server, and its user-space port cwfs were also built around versioning. By default, the cached-worm systems are dumped at 5am every day in the morning, meaning you can access your files as they were at 5am every day. You can manually dump them whenever you please, of course. These dumps are cheap, but not as cheap as fossil or ZFS (or git) snapshots. Unlike ZFS (not sure about git), these dumps are immutable, you can't delete them. With fossil+venti, you still get daily dumps, but you also get finer grained ephemeral snapshots. By default at 15 minute intervals, I used to set them at 5 minutes. You can control how long you want to keep these in fossil, I kept mine for 3 months. The dumps are venti are immutable. These are very very cheap, and these systems also do deduplication, by default. I don't run fossil anymore, I like the features, but reliability was less than stellar for some people, and the performance is much lower than cwfs, which is what I use now. Cwfs is very fast, rock solid, and very easy to recover in case of a catastrophe. I miss ephemeral snapshots, but cwfs dumps are cheap enough I can run them for what in a normal system you'd do "commits" for. I miss all these features when I am forced to use Unix. Git does two things, history preservation and patch management. For history preservation, nothing beats the Plan 9 system. What git does better is patch management. I think it's valuable not to conflate these two concepts and create tools that can solve each one well, and work well together.

frik 12y ago

We should think more out of the box. BeOS BFS, (ReiserFS4) and early versions of NTFS supported extensive object oriented metadata and search capabilities ("Cairo") - something like WinFS but directly in the filesystem driver. Data could be organized like in relational databases today, you could find your data in various ways. Not just in the old and proven way of hierarchical directory tree. A modern filesystem that is available for common operating systems would be a good starting point. I am not sure if ZFS is the answer, there might be better FS around, but we need definitely rock-solid file system drivers that we can rely on for WinNT 5+ and current OSX (as well as Linux and *BSD but at least ZFS has it for the later). At the moment the common determinator of all filesystem drivers are various editions of Microsoft FAT filesystem - a pretty basic and old filesystem by today's standards. NTFS as filesystem is very rock-solid and read & often also write support is available in all common OS. We would definitely benefit if solid r/w filesystem drivers like ext4, XFS, ReFS, BFS/BeFS, Btrfs, etc. would be available on more OS platforms.

sdrinf 12y ago
| We should think more out of the box. BeOS BFS, (ReiserFS4) and early versions of NTFS supported extensive object oriented metadata and search capabilities ("Cairo") - something like WinFS but directly in the filesystem driver. Data could be organized like in relational databases today, you could find your data in various ways. Not just in the old and proven way of hierarchical directory tree. The second you open that up to application layers, you are facing a wide range of problems. Specifically: * Common schema: each application considers itself a unique snowflake, and might want to use different columns to mean different sort of things. We've been here before -semantic web, RDF, etc- and the correct solution was letting the apps just manage their own database of stuff. * Selfish apps: There is nothing stopping apps from overwriting, or manipulating meta-info in ways that are detrimental to user experience. Consider the current case of "Set <x> as default browser", "Set <x> as default media player" at each launch, then multiply it across every schema column * Interop: Beos attempted to solve this by dumping meta-info into the archives. The problem is, when a file gets outside the original system/OS, these attributes will get truncated. Any workaround on this would require full agreement on changing all of the file transfer protocols, and storage methods on all OS. Also note, that the 90% of the case (localizing files instantly on multi-terabyte consumer-drives) is handled already via Windows Search & Finder. Personal experience on this shows, that you can safely drop the hierarchical madness in favor of filename-based search for most media/music/document cases; and there are ways you can apply this for development as well.

pan69 12y ago

I was actually interested in running a ZFS set up but after talking to some people they advised me not to run ZFS on a system without ECC memory. Reason being, if corrupt memory would be written into your ZFS set up you won't be able to recover from it. I'm curious about any further thoughts/experience on this.

ossreality 12y ago
how is that unique to zfs?
thecabinet 12y ago
One of you missed the point. The reason ECC is suggested with ZFS is because all of the other features (RAIDZ and checksumming in particular) don't do any good if your data gets corrupted in memory. This is true for all filesystems, but most of them don't try as hard to protect your data in the first place.
- pan69 12y ago
  I could very well have got it wrong but the way I understand it was that in a file system such as ext4, if a file is somehow corrupted in memory and written to disk you might not be able to recover from this and the file might become useless. However, with ZFS you would lose "all" your files in the file system. Again, I might have misunderstood.
  - Elhana 12y ago
    Example of non-ecc memory corruption and effect: http://comments.gmane.org/gmane.os.illumos.zfs/1779 http://comments.gmane.org/gmane.os.illumos.zfs/1779
  - makomk 12y ago
    Wouldn't surprise me, ZFS is pretty bad at recovering from metadata corruption.
    - 12y ago

yamadapc 12y ago

As the article seems to be down, here's the text-only (google) cached version: http://webcache.googleusercontent.com/search?q=cache:CTMc7ZQuOB4J:zef.me/6023/who-needs-git-when-you-got-zfs&strip=1 http://webcache.googleusercontent.com/search?q=cache:CTMc7ZQ...

cryptonector 12y ago

git is not reliable in the face of power failures. I believe this is due to insufficient care taken in writing to reflogs and packs when receiving. (Reflogs are appended to, for example, while objects are first written to, fsync'ed, then renamed into place, so object writing is incrementally atomic, while everything else... not so much.) Fossil uses SQLite3, but it doesn't do what I want -- only git gives me the power of the index, rebase, and light-weight branches. (OK, Mercurial has those too, but it's too late and it sucks. Sorry.) Fossil does get several important things from using SQLite3: SQL for history (do NOT underestimate this), extensibility (one file format, trivially extensible schema), well-tested ACID semantics support. Oh, one more thing: using SQLite3 minimizes fsyncs per-transaction. There's probably more benefits, actually. And ZFS? Well, ZFS snapshots give you ACID. If you have a persistent ZIL then fsync() gives you barriers (nice!). But a) snapshots are slow by comparison to SQLite3 COMMITs, and b) you don't get the benefit of SQL. Oh: and not everyone can haz ZFS, but everyone can haz git. Everyone also can has SQLite3. My proposal: backend git's I/O abstraction layer (which is pretty nice) with SQLite3. And if you have ZFS, then always take a snapshot in a post-receive hook; destroy older snapshots later in a cronjob. (As for zfs destroy, you really want the async zfs destroy feature, which IIRC not every implementation has!)

cryptonector 12y ago
I'd really like reflogs and branches to themselves be objects. Only packs (maybe) and tags (also maybe) should not be objects. If reflogs were objects then... they could be pushed and pulled, which would be really nice indeed. If branches were objects then they could record rebase history. I would really like to be able to capture rebase history: what a branch's HEAD was before and after a rebase, as well as the picks/squashes/edits/rewords/drops done in an interactive rebase, and even the merge pre-/post-base (--onto).

songco 12y ago

Where is github for zfs?