Messages in this thread | | | Date | Fri, 2 Jan 2004 20:56:21 +0100 | From | Jörn Engel <> | Subject | Re: Syscall table AKA hijacking syscalls |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |