Messages in this thread | | | From | Nix <> | Date | Mon, 6 Mar 2000 19:40:05 +0000 (GMT) | Subject | Re: cow-links |
| |
> 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/
| |