[RFC] Copy on First Read?

[RFC] Copy on First Read?

[Roger Larsson]

I have been thinking about a file system that uses Copy On First Read.
My idea looks like this:

1. Split the disk in three parts (unused, write, used - could be growing from 
top and bottom like heap and stack)
2. Writes goes to one part - log structured, like a tape. Fragmentation of 
files are OK, but buffering is done to prevent the worst cases.

This to allow fast write of huge amounts of data.

Later when the file is first read
* the size is known.
* is probably read together with other files that in future will be used
   together.

So the allocation rule for the copy on first read can use these facts.
Only files that are actually used will be read and thus rewritten.

This will leave unused files in the write part. This old files can be 
compacted to and moved to the 'unused' part to give a continuous area to
use as write part. These files could even be moved to a slower media
(if available).

Log files will remain in 'write/unused' sections until searched.

Comments?

/RogerL

Re: [RFC] Copy on First Read?

[Andreas Dilger]

On Jul 10, 2006  09:04 +0200, Roger Larsson wrote:
> I have been thinking about a file system that uses Copy On First Read.
> My idea looks like this:
> 
> 1. Split the disk in three parts (unused, write, used - could be growing from 
> top and bottom like heap and stack)
> 2. Writes goes to one part - log structured, like a tape. Fragmentation of 
> files are OK, but buffering is done to prevent the worst cases.
> 
> This to allow fast write of huge amounts of data.
> 
> Later when the file is first read
> * the size is known.
> * is probably read together with other files that in future will be used
>    together.
> 
> So the allocation rule for the copy on first read can use these facts.
> Only files that are actually used will be read and thus rewritten.
> 
> This will leave unused files in the write part. This old files can be 
> compacted to and moved to the 'unused' part to give a continuous area to
> use as write part. These files could even be moved to a slower media
> (if available).
> 
> Log files will remain in 'write/unused' sections until searched.

It doesn't sound significantly different than a regular log-structured
filesystem.  You still need a cleaner thread to move files around and
keep the free space contiguous.  Since this is (in essence) data journaling
all writes, you need to have double the disk bandwidth in order to rewrite
all of the files that are read.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

Re: [RFC] Copy on First Read?

[Roger Larsson]

On Monday 10 July 2006 10:27, Andreas Dilger wrote:
> On Jul 10, 2006  09:04 +0200, Roger Larsson wrote:
> > I have been thinking about a file system that uses Copy On First Read.
> > - - -

> It doesn't sound significantly different than a regular log-structured
> filesystem.  You still need a cleaner thread to move files around and
> keep the free space contiguous.

It is needed but shouldn't have that much to do. Unless most files are
never read...

> Since this is (in essence) data journaling 
> all writes, you need to have double the disk bandwidth in order to rewrite
> all of the files that are read.

Not double since it is only the first read after a write that needs to be 
rewritten. My assumption is that most files are written fewer times than
they are read. And the read for the copy is free since that was what
triggered it.

Config files - few changes, many reads.
Media files - one write, (probably) many reads.
Office files - more reads than writes.
Log files - many writes, few reads.
. . .

/RogerL

Re: [RFC] Copy on First Read?

[Theodore Tso]

On Mon, Jul 10, 2006 at 12:25:46PM +0200, Roger Larsson wrote:
> Not double since it is only the first read after a write that needs to be 
> rewritten. My assumption is that most files are written fewer times than
> they are read. And the read for the copy is free since that was what
> triggered it.

But there is a cost, and the question is how much does this buy you
compared to simply getting it right the first time, either via a
delayed allocation scheme, or where the application knows how big the
file is up front (as is often the case).   

In addition your scheme is extremely pessimal behaviour for temporary
files which are writtena and read once before being deleted....

						- Ted

Re: [RFC] Copy on First Read?

[Roger Larsson]

On Monday 10 July 2006 19:59, Theodore Tso wrote:
> On Mon, Jul 10, 2006 at 12:25:46PM +0200, Roger Larsson wrote:
> > Not double since it is only the first read after a write that needs to be
> > rewritten. My assumption is that most files are written fewer times than
> > they are read. And the read for the copy is free since that was what
> > triggered it.
>
> But there is a cost, and the question is how much does this buy you
> compared to simply getting it right the first time, either via a
> delayed allocation scheme, or where the application knows how big the
> file is up front (as is often the case).

But is the size of the file ALL that is needed?
Isn't it interesting to make use of
- What is it written together with.
- What is it read together with.

Lets take a look at a use case, downloading and compiling a kernel.

Download goes to the write buffer, delayed enough to notice that it is big.
tar to extract
	read triggers a copy operation -> copy can be made continuous since the
	size is known. This results in two continuous writes one for the copy
	operation. The other for extracted files put in 'write' part.
make oldconfig
	config file related stuff will be copied from 'write'.
make
	copy files together as they are used.
	object files are written to 'write' part - continously.
	link will move them together as they are used.
	(Yes, temporary files is a problem - delayed write?)

Redoing a make should do quite well regarding where files are placed relative
to each other...
Does other allocation schemes really do better without later moving the files?

/RogerL