Messages in this thread | | | Date | Mon, 3 Sep 2001 17:11:36 +0200 (CEST) | From | Richard Guenther <> | Subject | Re: Editing-in-place of a large file |
| |
On Mon, 3 Sep 2001, Bob McElrath wrote:
> Alan Cox [alan@lxorguk.ukuu.org.uk] 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 <richard.guenther@uni-tuebingen.de> WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |