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 se
> 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 Oct 6, 2006, at 1:07 AM, Michael Schuster wrote:
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 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 tim
On Sep 28, 2006, at 1:54 AM, Chad Leigh -- Shire.Net LLC wrote:
On Sep 26, 2006, at 12:26 PM, Chad Leigh -- Shire.Net LLC wrote:
On Sep 26, 2006, at 12:24 PM, Mike Kupfer wrote:
"Chad" == Chad Leigh <-- Shire.Net LLC" <[EMAIL PROTECTED]>>
writes:
Chad> snoop does not show me the reply
> 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
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. Jus
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 o
> 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 dem
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
Hello,
On 10/6/06, [EMAIL PROTECTED] <[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 connec
On Thu, Oct 05, 2006 at 02:19:46PM -0700, Erik Trimble wrote:
> Doing versioning at the file-system layer allows block-level changes to
> be stored, so it doesn't consume enormous amounts of extra space. In
> fact, it's more efficient than any versioning software (CVS, SVN,
> teamware, etc) for
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 snapsh
2. The ability to retain old versions of a portion of the file system without
needing to keep old versions of everything.
If I want to keep older versions of my source code but free up the object
files, there’s no way to do that with snapshots (unless I keep them in separate
file systems). File
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 10/5/06, Wee Yeh Tan <[EMAIL PROTECTED]> wrote:
On 10/6/06, David Dyer-Bennet <[EMAIL PROTECTED]> wrote:
> One of the big problems with CVS and SVN and Microsoft SourceSafe is
> that you don't have the benefits of version control most of the time,
> because all commits are *public*.
David,
T
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
[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 immedia
On Oct 6, 2006, at 1:02 PM, Matthew Ahrens 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 snapshot
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
10:27
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 pe
On Fri, Oct 06, 2006 at 12:02:16PM -0700, Matthew Ahrens wrote:
> In my opinion, the marginal benefit of per-write(2) versions over
> snapshots (which can be per-transaction, ie. every ~5 seconds) does not
> outweigh the complexity of implementation and use/administration.
Per-write(2) versions
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 m
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. Fi
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 wo
[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 -
export/z
On Oct 6, 2006, at 3:14 PM, Erik Trimble wrote:
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 te
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 t
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 fil
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 simpl
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 o
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/htm
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 r
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 tools
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 with
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 an
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
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 ve
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
nam
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? Etc..
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 T
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 ed
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
Erik Trimble wrote:
The developers can answer this definitively, but I believe the answer
to your questions is NO. That is, if there is anything in the buffer
waiting to be written when a snapshot request comes along, the buffer
is written out so that the file is consistent with the last wr
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
>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 u
>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 eas
>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
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 t
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 ver
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 rea
On Oct 6, 2006, at 12:18 PM, David Dyer-Bennet wrote:
On 10/5/06, Wee Yeh Tan <[EMAIL PROTECTED]> wrote:
On 10/6/06, David Dyer-Bennet <[EMAIL PROTECTED]> wrote:
> One of the big problems with CVS and SVN and Microsoft
SourceSafe is
> that you don't have the benefits of version control most of
60 matches
Mail list logo
