I seem to remember that one could configure the max. number of versions VMS
would retain for you on a per-file basis - setting this to 1 would de facto
turn off versioning.
IFF versioning were implemented in ZFS, AND was made configurable on a
per-file basis (everything else wouldn't make any
What would a version FS buy us that cron+ zfs
snapshots doesn't?
Some people are making money on the concept, so I
suppose there are those who perceive benefits:
http://en.wikipedia.org/wiki/Rational_ClearCase
(I dimly remember DSEE on the Apollos; also some sort of
versioning file type on
On Fri, Oct 06, 2006 at 01:14:23AM -0600, Chad Leigh -- Shire.Net LLC wrote:
But I would dearly like to have a versioning capability.
Me too.
Example (real life scenario): there is a samba server for about 200
concurrent connected users. They keep mainly doc/xls files on the
server. From time
Stefan Urbat wrote:
zfs --- the performance of [EMAIL PROTECTED] is indeed rather
poor (much worse
than ufs), but this is another, already documented
and bug entry
honoured issue.
Really? Are you allowing ZFS to use the entire disk
(and thus turn on
the disk's write cache)?
No, I
On Thu, 5 Oct 2006, Erblichs wrote:
Casper Dik,
After my posting, I assumed that a code question should be
directed to the ZFS code alias, so I apologize to the people
show don't read code. However, since the discussion is here,
I will post a code proof here.
Group,
This example is done with a single threaded app.
It is NOT NOT NOT intended to show any level of
Thread-safe type coding.
It is ONLY used to show that it is signifcantly lower cost
to grab pre-allocated objects than to allocate the
objects
On 05/10/06, Richard Elling - PAE [EMAIL PROTECTED] wrote:
Dick Davies wrote:
I very foolishly decided to mirror /grub using SVM
(so I could boot easily if a disk died). Shrank swap partitions
to make somewhere to keep the SVM database (2 copies on each
disk).
D'oh!
N.B. this isn't
A couple of use cases I was considering off hand:
1. Oops i truncated my file
2. Oops i saved over my file
3. Oops an app corrupted my file.
4. Oops i rm -rf the wrong directory.
All of which can be solved by periodic snapshots, but versioning gives
us immediacy.
So is immediacy worth it to you
On Fri, Oct 06, 2006 at 11:25:29PM +0800, Jeremy Teo wrote:
A couple of use cases I was considering off hand:
1. Oops i truncated my file
2. Oops i saved over my file
3. Oops an app corrupted my file.
4. Oops i rm -rf the wrong directory.
All of which can be solved by periodic snapshots,
ClearCase is a version control system, though — not the same as file versioning.
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Fri, Oct 06, 2006 at 09:18:16AM -0700, Anton B. Rang wrote:
ClearCase is a version control system, though — not the same as file
versioning.
But they have a filesystem interface. Crucially, this involves
additional interfaces. VC cannot be automatic.
On Fri, Oct 06, 2006 at 09:40:22AM +0200, [EMAIL PROTECTED] wrote:
Example (real life scenario): there is a samba server for about 200
concurrent connected users. They keep mainly doc/xls files on the
server. From time to time they (somehow) currupt their files (they
share the files so it is
[EMAIL PROTECTED] wrote:
On Fri, Oct 06, 2006 at 01:14:23AM -0600, Chad Leigh -- Shire.Net LLC wrote:
But I would dearly like to have a versioning capability.
Me too.
Example (real life scenario): there is a samba server for about 200
concurrent connected users. They keep mainly doc/xls files
Jeremy Teo wrote:
A couple of use cases I was considering off hand:
1. Oops i truncated my file
2. Oops i saved over my file
3. Oops an app corrupted my file.
4. Oops i rm -rf the wrong directory.
All of which can be solved by periodic snapshots, but versioning gives
us immediacy.
So is
Matthew Ahrens wrote:
If you disagree, please tell us *why* you think snapshots don't solve
the problem.
Technically there's a race condition here. If you're taking regular
snapshots, you might see
10:25 - snapshot 1 - myfile.xls version 21
10:26 -- myfile.xls version 22
On 10/6/06, Matthew Ahrens [EMAIL PROTECTED] wrote:
Jeremy Teo wrote:
A couple of use cases I was considering off hand:
1. Oops i truncated my file
2. Oops i saved over my file
3. Oops an app corrupted my file.
4. Oops i rm -rf the wrong directory.
All of which can be solved by periodic
Chad Leigh -- Shire.Net LLC wrote:
disclaimer: I have not used zfs snapshots a lot as I am still
experimenting with zfs, but they appear to be similar to freebsd
snapshots, with which I am familiar.
The user experience with snapshots, in terms of file versioning (#1,
#2, maybe #3) is
First of all, let's agree that this discussion of File Versioning makes
no more reference to its usage as Version Control. That is, we aren't
going to talk about it being useful for source code, other than in the
context where a source code file is a document, like any other text
document.
Chad Leigh -- Shire.Net LLC wrote:
disclaimer: I have not used zfs snapshots a lot as I am still
experimenting with zfs, but they appear to be similar to freebsd
snapshots, with which I am familiar.
The user experience with snapshots, in terms of file versioning (#1,
#2, maybe #3) is much
[EMAIL PROTECTED]:~]# zfs list -r export/zone/www/html
NAME USED AVAIL REFER MOUNTPOINT
export/zone/www/html 20.9M 225G 10.4M /export/zone/www/html
export/zone/www/[EMAIL PROTECTED] 10.4M - 10.4M -
export/zone/www/[EMAIL PROTECTED] 0 - 10.4M -
On Oct 6, 2006, at 3:08 PM, Erik Trimble wrote:
First of all, let's agree that this discussion of File Versioning
makes no more reference to its usage as Version Control. That is,
we aren't going to talk about it being useful for source code,
other than in the context where a source code
Frank Cusack wrote:
[EMAIL PROTECTED]:~]# zfs send -i export/zone/www/[EMAIL PROTECTED] export/zone/www/[EMAIL PROTECTED]
| ssh cookies zfs recv export/zone/www/html
cannot receive: destination has been modified since most recent snapshot --
use 'zfs rollback' to discard changes
I was going
On 10/6/06, Erik Trimble [EMAIL PROTECTED] wrote:
First of all, let's agree that this discussion of File Versioning makes
no more reference to its usage as Version Control. That is, we aren't
going to talk about it being useful for source code, other than in the
context where a source code file
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
On October 6, 2006 2:34:36 PM -0700 Matthew Ahrens [EMAIL PROTECTED]
wrote:
Frank Cusack wrote:
[EMAIL PROTECTED]:~]# zfs send -i export/zone/www/[EMAIL PROTECTED]
export/zone/www/[EMAIL PROTECTED]
| ssh cookies zfs recv export/zone/www/html
cannot receive: destination has been modified since
On Oct 6, 2006, at 3:53 PM, 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
Frank Cusack wrote:
If you can't run build 48 or later, then you can workaround the problem
by not mounting the filesystem in between the 'rollback' and the 'recv':
cookies# zfs set mountpoint=none export/zone/www/html
cookies# zfs rollback export/zone/www/[EMAIL PROTECTED]
milk# zfs send -i @4
On 10/6/06, Nicolas Williams [EMAIL PROTECTED] 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
On October 6, 2006 3:09:09 PM -0700 Matthew Ahrens [EMAIL PROTECTED]
wrote:
Frank Cusack wrote:
If you can't run build 48 or later, then you can workaround the problem
by not mounting the filesystem in between the 'rollback' and the 'recv':
cookies# zfs set mountpoint=none export/zone/www/html
Frank Cusack wrote:
No, I just tried the @[EMAIL PROTECTED] incremental again. I didn't think to
try
another incremental. So I was basically doing the mountpoint=none trick,
they trying @[EMAIL PROTECTED] again without doing mountpoint=none.
Again, seeing the exact sequence of commands you
Chad,
I think our problem is that we look at FV from different angles. I look
at it from the point of view of people who have NEVER used FV, and you
look at it from the view of people who have ALWAYS used FV.
For those of us who have never had FV available, technical users have
used VC
On October 6, 2006 3:42:48 PM -0700 Matthew Ahrens [EMAIL PROTECTED]
wrote:
Frank Cusack wrote:
No, I just tried the @[EMAIL PROTECTED] incremental again. I didn't think to
try
another incremental. So I was basically doing the mountpoint=none trick,
they trying @[EMAIL PROTECTED] again
Frank Cusack wrote:
Really? I find it hard to believe that mountpoint=none causes any more
problems than 'zfs recv' by itself, since 'zfs recv' of an incremental
stream always unmounts the destination fs while the recv is taking place.
You're right. I forgot I was having problems with this
On Fri, Oct 06, 2006 at 04:06:37PM -0600, Chad Leigh -- Shire.Net LLC wrote:
On Oct 6, 2006, at 3:53 PM, 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
On 10/6/06, Nicolas Williams [EMAIL PROTECTED] wrote:
On Fri, Oct 06, 2006 at 04:06:37PM -0600, Chad Leigh -- Shire.Net LLC wrote:
On Oct 6, 2006, at 3:53 PM, Nicolas Williams wrote:
Maybe Erik would find it confusing. I know I would find it
_annoying_.
Then leave it set to 1 version
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
Nicolas Williams wrote:
The big question though is: how to snapshot file versions when they are
touched/created by applications that are not aware of FV?
Certainly not with every write(2). At fsync(2), close(2), open(2) for
write/append? What if an application deals in multiple files?
David Dyer-Bennet wrote:
On 10/6/06, Nicolas Williams [EMAIL PROTECTED] wrote:
Maybe Erik would find it confusing. I know I would find it
_annoying_.
Then leave it set to 1 version
Per-directory? Per-filesystem?
Whatever. What's the actual issue here?
I don't recall that on TOPS-20
On Oct 6, 2006, at 7:33 PM, Erik Trimble wrote:
This is what Nico and I are talking about: if you turn on file
versioning automatically (even for just a directory, and not a
whole filesystem), the number of files being created explodes
geometrically.
But it doesn't. Unless you are
Joseph Mocker wrote:
Nicolas Williams wrote:
The big question though is: how to snapshot file versions when they are
touched/created by applications that are not aware of FV?
Certainly not with every write(2). At fsync(2), close(2), open(2) for
write/append? What if an application deals in
On Oct 6, 2006, at 7:33 PM, Erik Trimble wrote:
David Dyer-Bennet wrote:
On 10/6/06, Nicolas Williams [EMAIL PROTECTED] wrote:
Maybe Erik would find it confusing. I know I would find it
_annoying_.
Then leave it set to 1 version
Per-directory? Per-filesystem?
Whatever. What's the
I think our problem is that we look at FV from different angles. I look
at it from the point of view of people who have NEVER used FV, and you
look at it from the view of people who have ALWAYS used FV.
That's certainly a part of it. It's interesting reading this discussion, as
someone who
People are oriented to their files, not to snapshots.
True, though with NetApp-style snapshots, it's not that difficult to translate
'src/file.c' to '.snapshot/hourly.0/src/file.c' and see what it was like an
hour ago. I imagine that a syntax like '.snapshot/22:20/src/file.c' would also
be
Versioning cannot be automated; taking periodic snapshots != capturing
application state.
But I think we have existence proofs of operating systems which do automate
versioning.
It's true that capturing a new version each time a file has been modified and
closed may not be perfect, but if it
Erik Trimble wrote:
The problem is we are comparing apples to oranges in user bases here.
TOPS-20 systems had a couple of dozen users (or, at most, a few
hundred). VMS only slightly more. UNIX/POSIX systems have 10s of
thousands.
IIRC, I had about a dozen files under VMS, not counting
On Oct 6, 2006, at 10:18 PM, Richard Elling - PAE wrote:
Erik Trimble wrote:
The problem is we are comparing apples to oranges in user bases
here. TOPS-20 systems had a couple of dozen users (or, at most, a
few hundred). VMS only slightly more. UNIX/POSIX systems have
10s of thousands.
On Oct 6, 2006, at 23:42, Anton B. Rang wrote:I don't agree that version control systems solve the same problem as file versioning. I don't want to check *every change* that I make into version control -- it makes the history unwieldy. At the same time, if I make a change that turns out to work
47 matches
Mail list logo
