Re: Syscall table AKA hijacking syscalls

Jörn Engel
2004-01-02T19:56:29Z

On Fri, 2 January 2004 20:37:37 +0100, Libor Vanek wrote:
>
> >If you take a snapshot on every change within your scope, it doesn't
> >really matter whether you do it before or after the change. Before
> >change n is just after change n-1. All you have to do is take another
> >snapshot before the first change, that is the special case.
>
> But this special case in fact means to copy all the data, if wanted to do
> it 100% working ;-) And I suggest that it wont' go through my exam ;)

Yes, it does. Cannot comment on your exam, though.

> >Actually, with userspace notification in place, you could even get
> >this with just cvs. Whenever a file is changed, commit. cvs add on
> >creation, etc. Yes, it sucks, but implementation simplicity has it's
> >own beauty and it would only take a few minutes. :)
>
> I've heard about some fs from Microsoft which should have cvs-like
> behaviour for all the time ("I want this file version from yesterday") -
> but I haven't had any details (and I suppose performance hit must be big)

Not too big, actually. The obvious implementation has to write data
twice (plus metadata, but that's minimal), so performance is ~50% of
normal. With hard drives and a smarter implementation, you don't have
to worry about seek latency too much for the log, so performance is
usually better than 50%. Basically, it hurts where you are good
enough anyway (large sequential writes) and goes unnoticed where
performance is bad (many small scattered writes).

The real problem is storage size. Each write will *permanently*
reduce the filesystem size. Maxtor and friends should happily sponsor
such development. :)

Seriously, such a thing is the perfect cure for "rm -rf foo /" and
similar famous mistakes and you can always just remove the oldest
backup data (preferrably after writing it to a tape).

Jörn

--
A defeated army first battles and then seeks victory.
-- Sun Tzu