[lkml]   [2001]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Editing-in-place of a large file
On Mon, Sep 03, 2001 at 02:31:58AM +0100, Alan Cox wrote:
> Another approach would be to keep your own index of blocks and use that
> for the data reads.

That is reimplementing file system functionality in user space.
I'm in doubts that this is considered good design...

But I've done a similar thing anyway (using a ordered list of
continous mmap()ed chunks) some years ago (see my other posting
in this thread mentioning C++) ;-)

> Since fdelete and fzero wont actually relayout the files in
> order to make the data linear (even if such calls existed)
> there isnt much point performancewise doing it in kernel space

That's the problem of the file system to be used. And the data
doesn't need to be linear. Current file systems on Linux only
avoid fragmentation, but they don't actively fight it by moving
things around, so this doesn't matter anyway.

> - its a very specialised application

Editing video and audio streams is more common then you think and
letting the user wait, while we copy 4GB around is not what I
consider user friendly, even for the selective user friendlyness
of a Unix ;-)


Ingo Oeser
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:01    [W:0.123 / U:1.696 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site