Re: Editing-in-place of a large file

[Richard Guenther]

On Mon, 3 Sep 2001, Bob McElrath wrote:

> Alan Cox [[e-mail]] wrote:
> > > That is reimplementing file system functionality in user space. 
> > > I'm in doubts that this is considered good design...
> > 
> > Keeping things out of the kernel is good design. Your block indirections
> > are no different to other database formats. Perhaps you think we should
> > have fsql_operation() and libdb in kernel 8)
> 
> Well, a filesystem that is:
> 1) synchronous
> 2) bypasses linux's buffer cache
> 3) insert() and delete() to insert and delete from the middle of a file.
> 4) Has large block sizes

Well, just make it possible to tell something more about the operation
you want to do to the kernel/VFS. Copy/Insert/Delete is in fact some
sort of sendfile operation. For GLAME I did a "simple" (well, it turned
out to be not that simple...) user level filesystem that supports those
kind of operations. The interface I chose was
  sendfile(dest_fd, source_fd, count, mode)
where mode can be composed out of nothing (overwrite, leave source
intact), INSERT and CUT.

As it is a userspace implementation byte granularity is supported, but
for a kernel level support I suppose block granularity would suffice and
could be optimized for in the lower level filesystems code. I'd prefer
such a generic interface over fcntls which would certainly be possible
at least for a "split this file into two ones" operation.

Oh yes - it would help to have this in the kernel, at least if you
want to support sane mmap behaviour (for block aligned modifications,
of course - byte level is impossible due to aliasing issues, I believe).

Richard.

--
Richard Guenther <[e-mail]>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/