zfs discuss - Jun 2011 - Versioning FS was: question about COW and snapshots

--- erik.trimble at oracle.com wrote:
|> So, if your apps have to be programmed to be 
|> versioning/consistency/checkmarking aware in any case, how 
|> would having a fancy Versioning filesystem be any better 
|> than using what we do now? 
|> (i.e. svn/hg/cvs/git on top of ZFS/btrfs/et al)   
|> ZFS at least makes significant practical advances by rolling 
|> the logical volume manager into the filesystem level, but 
|> I can''t see any such advantage for a Versioning FS.

Given what I''ve read here. Then the advantage of /a/ versioning FS,
would be to have calls that make it easy for the app to
version/checkmark/rollback individual files, and not have to worry about the
details on how that is handled. The FS can make multiple copies, or just store
deltas as it sees appropriate. The app can look for matching "revision
tags" and/or auto-rollback on corrupt files.

So the magic FS a few people want (and I wouldn''t mind) can''t
exist.  But having an interface, AND getting apps to use it, when that is common
enough between multiple OSes/FSes...

So the problems are properly defining the interface (technical).  Getting enough
support between the "major" file systems (social), dealing with slow
upgrading and backwards capability (time), and then finally getting enough apps
using the interface (technical & social).

As Casper pointed out, the right thing to do is to build applications
such that they can detect mid-transaction state and roll it back (or
forward, if there''s enough data).  Then mid-transaction snapshots are
fine, and the lack of APIs by which to inform the filesystem of
application transaction boundaries becomes much less of an issue
(adding such APIs is not a good solution, since it''d take many years
for apps to take advantage of them and more years still for legacy
apps to be upgraded or decomissioned).

The existing FS interfaces provide enough that one can build
applications this way.

Nico
--