> Some of us _use_ the sane behaviour of sane editors (vi, for one) in
> setups where the source tree is linked to the build tree and editing in
> one of them is supposed to affect both.
At no point did any of us say `ooh, let's dump hard links and make them
COW'; we said `let's add COW links too', or (in my case) `let's coalesce
blocks arbitrarily, oh, and btw, I have an algorithm'[1].
Coalescence of arbitrary blocks in the background is *good*.
(Ah. You said that below. Good to see you retain common sense. ;) )
> Sigh... Forget about MS abomination of the week - they mixed several
> different issues for no good reason.
Never! MS would never do that!
> 1) COW files. Makes sense, but must be done on block level instead
> of inode one. That is actually an old idea and quite a useful one. Think
In versioned fsen, yes. Outside of versioned fsen, it has not really
been done much.
> of filesystem acting as cache for WORM and getting regular NetApp-style
> backups.
Caching? I suppose so.
The coalescence is sort of the same idea, only the right way
around. Coalescence has extra interesting problems if done in a
completely general fashion, like `how can you tell if arbitrary
non-block-aligned chunks of data are identical so that *they* can be
merged, too'. Plus of course how to do all of this withut eating too
much system time, and, more importantly, too much disk time. (We don't
want to constantly max out the disk because that'd get in the way of
foreground task requests.)
> 3) crappy way to save disk space - properly solved by unionfs.
MS's `ooh let's replace files on n machines with one file on a
single-point-of-failure without thinking about failover' is horrible, of
course, sort of like an automatic NFS with the downside that it
encourages you not to think about failure issues on a file-by-file basis
(just like most MS stuff, in fact; discouraging thinking).
Arbitrary coalescence is nearly ideal. The only obvious way to do
better than that is to go the whole hog and convert chunks of data into
algorithms describing that data. (Of course, if you can manage to do
*that* over the entire disk, you have a disk with data packed as
efficiently as theory will permit. Working out the algorithms best
suited to encode given runs of data and doing it *at runtime* could be
fun, though. I see a need for strong AI to help. ;) )
[1] I proved that said algorithm can't work earlier today, but I think
it can be fixed. When it seems to be fixed I'll post it so other
people can shoot it full of holes too.
--
`> KNOWLEDGE AND SKILLS
You must have some, but I don't see any evidence of it.'
--- Craig Hardie flames a luser recruitment consultant
advertising `Microsoft based solutions' on uk.comp.os.linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:21 EST