> From: Nix <nix-kernel@esperi.demon.co.uk>
> Date: 05 Mar 2000 01:31:41 +0000
> Subject: Re: cow-links
>
> Bjorn Wesen <bjorn@sparta.lu.se> writes:
>
> > Maybe we can get Stephen Tweedie and the other FS "sharks" to comment
> > on this ?
>
> FWIW I have been working on the design for such a filesystem (or
> `filesystem block-allocation indirection layer') for a few months now.
Well, I would have been surprised if nobody had been researching this kind
of approach...
> Designing an efficient coalescer is harder than it seems.
I never thought it was easy -- I actually I wasn't sure if it was
realistically possible ;). OTOH, inode level cow-links do not seem too
complicated at first thought.
> There are
> numerous tradeoffs that change dynamically and which can be hard to fix.
> e.g., you do not just want to hash each inode and then diff the hashes
> to tell if two blocks should be coalesced, because an inode is a rather
> coarse unit; the smaller the hashed unit, the smaller the units that can
> be coalesced.
I see. But there are special cases where you don't have to hash to know
that units can be coalesced. Copying (ln --cow-link or something) is one
example.
Actually, there are filesystems available and developed that do not lose
the deleted files or older versions changed files. Instead, they make a
new copy on change, and later you can mount for example "last mondays"
situation. In certain applications, that is very useful. These fs's
propably use a kind of per-file or per-inode cow-link, but I wouldn't be
surprised if a more fine grained coalescence exploitations were possible.
And perhaps even compression.
> (FWIW the eventual goal for this fs includes lots more than merely block
> coalescence. We hope to be able to collapse blocks describable by an
> algorithm and dataset smaller than the block into that algorithm, so
> that if you took one of these fsen and left it for ages you'd end up
> with information packed onto that disk as optimally as information
> theory permits... of course on an fs that is being used it would never
> get near this ;)
So I guess this means compression to put it simply?
> Think of this as `Kolgomorov's Revenge'... ;) )
>
> [1] I do it in the background; the embryonic research OS this filesystem
> is being developed for has a *lot* of threads churning away in the
> background, doing dynamic optimizations of all kinds. Researching
> these dynamic optimizations is the whole raison d'etre of this OS...
Sounds interesting. Is there any information available of this research
OS, or is it developed behind closed doors?
-- v --
-
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:18 EST