Messages in this thread |  | | Date | Mon, 3 Sep 2001 03:50:25 +0200 | From | Ingo Oeser <> | Subject | Re: 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 ;-)
Regards
Ingo Oeser - 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/
|  |