> So, if I build it, people will want it? ;)
I think implementing this feature would help Apple adopt ZFS for Time Machine,
which is essentially a versioning FS in practice. Actually I don't know if
Apple does this, but you can increment versions with kernel notifications of
file changes (Spot
I was in the middle of doing a large transfer to my ZFS pool over CIFS. Near
the end of the transfer, the Solaris machine froze. Both ethernet links were
down.
I walked over to the machine and pushed the reset button, as it wouldn't
respond to any key-presses. After the machine booted up, I
Joseph Mocker wrote:
Which brings me back to the point of file versioning. If an
implementation were based on something like when a file is open()ed
with write bits set. There would be no potential for broken files like
this.
I'm showing my lack of knowledge on this one but I thought SAM-
Erik Trimble wrote:
Joseph Mocker wrote:
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
Spencer Shepler writes:
> On Tue, eric kustarz wrote:
> > Ben Rockwood wrote:
> > >I was really hoping for some option other than ZIL_DISABLE, but finally
> > >gave up the fight. Some people suggested NFSv4 helping over NFSv3 but it
> > >didn't... at least not enough to matter.
> > >
> >
Just to put the references I read in the past about it:
http://www.microsoft.com/technet/windowsvista/library/4ac505e6-dd8b-4ae7-80fa-b9d77cd8104d.mspx
Windows 2003 Derver implementation (for server side copies of client user files)
Working with the Windows Server 2003 Volume Shadow Copy Service
"A. C. Censi" <[EMAIL PROTECTED]> wrote:
> It seems that Windows 2003 (and VIsta will too), supports file
> versioning. I am not familiar with the implementation. AFAIR it is
> using the "alternate data stream" builtin in NTFS, to work with the
> versions and hide the versions from the user.
>
Th
Now, RAIDZn should beat RAID-5 since it tends to queue up writes until
it can write a full stripe at once (right?)
correct.
so you will get _less_
writes required, but it still has the same problem for sparse writes
(i.e. small writes spaced far apart on the disk layout, where writes t
It seems that Windows 2003 (and VIsta will too), supports file
versioning. I am not familiar with the implementation. AFAIR it is
using the "alternate data stream" builtin in NTFS, to work with the
versions and hide the versions from the user.
Certainly in Vista they will have to handle at least
Well, the drives technically didn't "malfunction".
Like I said, the reason why I had to pull the drives out is because 70 lbs is a
little TOO much for me to be able to lift.
The drives aren't more than 3 weeks old, with a DOM of Jul 2006.
Is there anything that I can do to find out how the syst
"Anton B. Rang" <[EMAIL PROTECTED]> wrote:
> >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
Erik Trimble <[EMAIL PROTECTED]> wrote:
>
> In order for an FV implementation to be useful for this stated purpose,
> it must fulfill the following requirements:
>
> (1) Clean interface for users. That is, one must NOT be presented with
> a complete list of all versions unless explicitly asked
"David Dyer-Bennet" <[EMAIL PROTECTED]> wrote:
> 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 so
Nicolas Williams <[EMAIL PROTECTED]> wrote:
> 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 implement
"Jeremy Teo" <[EMAIL PROTECTED]> 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
Chad Leigh -- Shire.Net LLC wrote:
But see, that assumes you have a logout-type functionality to use.
Which indeed is possible for command-line usage, but then only in a
very limited way. During a typical session, I access almost 20
NFS-mounted directories. And anyone using autofs/automount t
Chad Leigh -- Shire.Net LLC wrote:
Plus, the number of files being created under typical
modern systems is at least two (and probably three or four) orders
of magnitude greater. I've got 100,000 files under /usr in Solaris,
and almost 1,000 under my home directory.
wimp :-) I co
Joseph Mocker wrote:
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 consi
> If you disagree, please tell us *why* you think snapshots don't solve the
> problem.
Three reasons.
First of all, unless we have per-file snapshots, there's no way to keep old
versions of particularly important files without keeping old versions of
everything else. If I have a 4 GB video in
On Oct 6, 2006, at 6:15 PM, Nicolas Williams wrote:
What I'm saying is that I'd like to be able to keep multiple
versions of
my files without "echo *" or "ls" showing them to me by default.
Hmm, what about file.txt -> ._file.txt.1, ._file.txt.2, etc? If you
don't like the _ you could use @
20 matches
Mail list logo
