I can only say that I am not using any form of preallocation and still get
acceptable performance, even if I am forced to use quite big buffers to
overcome to filesystem latencies.
I tried to compare ext2 to FAT, but I do not get visible differences in terms of
buffer usage spikes (= disk thread blocks for long time due to the filesystem
being busy).
Therefore I suspect it's not a matter of filesystem ( ext2 or FAT), but buffer
flushing I (update,bdlush) and metadata updating.
Anyway I hope that one day we will be able to simply use O_DIRECT and get
RAW I/O access on a per-file basis, doing directly disk from/to userspace
transfers.
I think that this would help us to greatly reduce the needed buffersizes when
doing audio multitrack recording.
does anyone know if/when this is planned ?
(2.3.x kernels already contain the O_DIRECT define, but it's currently ignored)
PS: Does anyone know how to make a RAW I/O device on a spare disk partition,
and then put an ext2 over it (running the whole partition in RAWIO mode) ?
Is that possible ?
If yes I could run my multitrack benchmarks to see how much we can gain in terms
of needed buffersizes (should get smaller by at least 1/4 or so).
Benno.
On Fri, 14 Apr 2000, Andrew Clausen wrote:
>
> Hi all,
>
> Any comments?
> Received: by alpha (mbox clausen)
> (with Cubic Circle's cucipop (v1.31 1998/05/13) Sat Apr 15 07:57:05 2000)
> X-From_: [EMAIL PROTECTED] Fri Apr 14 22:17:10 2000
> Received: from ginette.musique.umontreal.ca (ginette.MUSIQUE.UMontreal.CA
>[132.204.178.34])
> by mx.alphalink.com.au (8.9.3/8.9.3) with SMTP id WAA08844
> for <[EMAIL PROTECTED]>; Fri, 14 Apr 2000 22:17:08 +1000
> Received: (from majordom@localhost) by ginette.musique.umontreal.ca
>(950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA19455 for linux-audio-dev-list; Fri, 14
>Apr 2000 08:16:48 -0400
> Received: from renoir.op.net (renoir.op.net [207.29.195.4]) by
>ginette.musique.umontreal.ca (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id
>IAA19452 for <[EMAIL PROTECTED]>; Fri, 14 Apr 2000
>08:16:46 -0400
> Received: from op.net (d-bm2-0b.ppp.op.net [209.152.194.43]) by renoir.op.net
>(o1/$Revision: 1.18 $) with ESMTP id IAA22739 for
><[EMAIL PROTECTED]>; Fri, 14 Apr 2000 08:11:44 -0400 (EDT)
> Received: (from pbd@localhost) by op.net ($Revision: 1.2 $) id IAA11954; Fri, 14 Apr
>2000 08:10:10 -0400
> Date: Fri, 14 Apr 2000 08:10:10 -0400
> Message-Id: <[EMAIL PROTECTED]>
> From: Paul Barton-Davis <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [linux-audio-dev] info point on linux hdr
> Sender: [EMAIL PROTECTED]
> Precedence: bulk
> X-Mozilla-Status2: 00000000
>
> i mentioned in some remarks to benno how important i thought it was to
> preallocate the files used for hard disk recording under linux.
>
> i was doing more work on ardour yesterday, and had the occasion to
> create some new "tapes", of lengths from 2 to 40 minutes.
>
> the simple act of creating 24 5 minute WAV files on ext2, files in
> which every block has been allocated, takes at least 1 minute, perhaps
> as much as 2. i create the files by first opening them, then writing a
> zero byte every blocksize bytes (blocksize comes from stat(2)), except
> for the WAV header at the beginning.
>
> i hadn't done this in a while, but it reminded me of the
> near-impossibility of expecting the FS code to allocate this much disk
> space in real time under ext2. If someone knows of a faster way to
> allocate the disk space, please let me know. Its not that I have a
> problem right now, just wanted to point out this behaviour.
>
> --p
>
>
