linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org,
	Bob McElrath <mcelrath+linux@draal.physics.wisc.edu>
Subject: Re: Editing-in-place of a large file
Date: Mon, 3 Sep 2001 03:50:25 +0200	[thread overview]
Message-ID: <20010903035025.B802@nightmaster.csn.tu-chemnitz.de> (raw)
In-Reply-To: <20010903032439.A802@nightmaster.csn.tu-chemnitz.de> <E15diak-0000mq-00@the-village.bc.nu>
In-Reply-To: <E15diak-0000mq-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Mon, Sep 03, 2001 at 02:31:58AM +0100

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

  reply	other threads:[~2001-09-03  1:50 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-02 20:21 Editing-in-place of a large file Bob McElrath
2001-09-02 21:28 ` COW fs (Re: Editing-in-place of a large file) VDA
2001-09-09 14:46   ` John Ripley
2001-09-09 16:30     ` John Ripley
2001-09-10  2:43       ` Daniel Phillips
2001-09-10  2:58         ` David Lang
2001-09-09 17:41     ` Xavier Bestel
2001-09-10  1:29       ` John Ripley
2001-09-10  6:45         ` Ragnar Kjørstad
2001-09-14 10:06         ` Pavel Machek
2001-09-10 11:11       ` Ihar Filipau
2001-09-10 16:10         ` Kari Hurtta
2001-09-14 10:03     ` Pavel Machek
2001-09-10  9:28   ` VDA
2001-09-10  9:35     ` John P. Looney
2001-09-02 21:30 ` Editing-in-place of a large file Ingo Oeser
2001-09-03  0:59   ` Larry McVoy
2001-09-03  1:24     ` Ingo Oeser
2001-09-03  1:31       ` Alan Cox
2001-09-03  1:50         ` Ingo Oeser [this message]
2001-09-03 10:48           ` Alan Cox
2001-09-03 14:31             ` Daniel Phillips
2001-09-03 14:46             ` Bob McElrath
2001-09-03 14:54               ` Alan Cox
2001-09-03 15:42                 ` Doug McNaught
2001-09-03 15:11               ` Richard Guenther
2001-09-03 21:19             ` Ben Ford
2001-09-03  4:27       ` Bob McElrath
2001-09-03  1:30     ` Daniel Phillips

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010903035025.B802@nightmaster.csn.tu-chemnitz.de \
    --to=ingo.oeser@informatik.tu-chemnitz.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcelrath+linux@draal.physics.wisc.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).