Ville Herva <vherva@niksula.hut.fi> writes:
> > 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...
It is, after all, deeply cool, if it can be got to work.
> > 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.
No, but why not get the design right first time?
> 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.
If it has to be done manually, IMNSHO it is nearly useless. The whole
point of this is that redundancy that you *didn't know was redundant*
can be eliminated. (If you want redundancy for safety, FS replication
and/or RAID are the way to go; not accident.)
> 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
Agreed. Versioning is another `must-have' for this fs. We're nicking
ideas from all over the place, a *lot* from reiserfs. We're also, when
we have some code, going to be using the Reiserfs Rule --- also known as
McVoy's Lesson --- `benchmark, benchmark, benchmark!'.
> 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.
Definitely.
> > (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?
Yeah, basically. Only the compression algorithm is designed on-the-fly
for that data set.
(The maths nutter --- not I --- whose idea most of this was is still
working on it.)
> > [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?
It's too embryonic atm, the design is still thrashing back and
forth. One hopes something more will come of it in time. I'm probably
going to set up a mailing list for it soon; hopefully things will start
taking off.
--
`> 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:18 EST