On Oct 6, 2006, at 21:17, Joseph Mocker wrote:
Nicolas Williams wrote:
On Fri, Oct 06, 2006 at 03:30:20PM -0600, Chad Leigh -- Shire.Net
LLC wrote:
On Oct 6, 2006, at 3:08 PM, Erik Trimble wrote:
OK. So, now we're on to FV. As Nico pointed out, FV is going
to need a new API. Using the VMS convention of simply creating
file names with a version string afterwards is unacceptible, as
it creates enormous directory pollution,
Assumption, not supported. "Eye of the beholder."
No, you really need an API, otherwise you have to guess when to
snapshot
versions of files.
David Dyer-Bennet's post gives a hint of how this could be done
without any API. Simply augment a few system calls like open(),
unlink(), etc. Calls that can potentially change files. Since you
can't change a file unless is open()'ed with various write flags
like O_WRONLY, O_RDWR, etc, this could be an ideal place to create
the version.
One could probably write a "poor man's" FV LD_PRELOAD library to do
this without the filesystem's knowledge at all.
With the stackable approach, versionfs does this with compression and
a number of other configurable policies see:
http://filesystems.org/project-versionfs.html
It wouldn't be as efficient with space as could be done at the
filesystem level, but as someone said, disk is cheap.
true, but it's still finite - there's typically a notion of recycling
or cleaning that is introduced such as in elephant:
http://www.hpl.hp.com/personal/Alistair_Veitch/papers/elephant-hotos/
index.html
or certain versioning implementations that have been written around
SAM-FS and it's recycler policies using the archiver.log:
http://www.hmk-computer.com/docs/products/synstar_restoreme.htm
.je
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
