Hans Reiser wrote:
John Gilmore wrote:
On Monday 24 October 2005 19:08, Edward Shishkin wrote:
John Gilmore wrote:
How are plugin/file
relationships handled without it?
For the first time there will be an option in mkfs to assign a file
plugin for regular files per superblock.
Then (if everything will be okay) we will granulate the relationship.
Edward.
So the first beta of compression will only have the option to control it at
mkfs time?
It should be explained that on the first flush to disk of a new file the
default compress plugin will test to see if the first 64k is
compressable, and if it is not then it converts the file to a regular
file plugin.
a little correction:
this is a compression transform plugin that is converted at flush time,
not file plugin
Edward, confirm that you coded it that way, as I think I expressed
things more precisely this time.;-)
I believe most users will find most of their files get the right
treatment using this heuristic.
And then later on, compression control and status information will
be available on a per-file (or per-directory) basis via a user-space tool
operating on mounted filesystems? Which tool will also be extendable to
control and give status information (where applicable) on other types of
plugins?
Is there a page that I could go to - some sort of "Major feature changes" page
- to see what the current status of the filesystem is?
If you pay for the tech writer.:-/ We have less funding than most users
imagine we have.
To answer such
questions as "Is compression ready for beta?" and "what the heck happened to
file-as-directory?" and "I saw mention of a test of the reiser4 repacker, and
also mention of compile problems with repacker.c, which definitely doesn't
exist in MY version of resier4 - what gives?" (though I've concluded that
that last one must be somebodies copy of alpha software...)
