[lkml]   [2001]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Editing-in-place of a large file
Alan Cox [] 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

Sounds like a possibility for the kernel to me. As with most things,
you could do raw disk I/O from userspace, but it seems reasonable to put
it in the kernel. Call it "mediafs" or something.

I agree that "normal" filesystems like ext2 should not do the insert()
and delete() that were mentioned. It'd be a lot of work and could
easily get someone in to trouble (imagine doing it on small files!)

It appears that SGI's XFS does some of this in IRIX. They play some
tricks to keep from copying the streaming data. (i.e. same buffer gets
passed around as a target for the video device, a source for a userspace
program, and a source for DMA to disk) They also have some special
fcentl(fd, F_SETFL, FDIRECT); /* enables direct disk access */
open(filename, O_DIRECT); /* likewise */
See this page for details:

Can linux disable its buffer cache for a particular filesystem
(something like a 'nocache' mount option?)

-- Bob

Bob McElrath (
Univ. of Wisconsin at Madison, Department of Physics
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-03-22 13:01    [W:0.043 / U:1.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site