From: Stewart Smith <stewart@linux.org.au>
To: Horvath Gyorgy <HORVAATH@tmit.bme.hu>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [ANNOUNCE] New hardware - SGA155D dual STM-1/OC3 PCI ad
Date: Thu, 11 Sep 2003 00:05:08 +1000 [thread overview]
Message-ID: <1063202707.7632.25.camel@willster> (raw)
In-Reply-To: <1063119321.30379.19.camel@dhcp23.swansea.linux.org.uk>
On Wed, 2003-09-10 at 00:55, Alan Cox wrote:
> > 4. Optionally - and if I have enough time - I'd like
> > to develop a twin-linear filesystem driver for
> > time-stamped capture/playback for multiple channels
> > of data - like a multi-band magnetic tape.
> > BTW do you know an existing one?
>
> I've seen people do this in user space (just interleaving the disk in
> big chunks in the app and driving it with O_DIRECT raw access) but not
> in kernel file system space.
(from memory) I think that ext2/ext3 does (or at least did) this - they
lacked any smart logic for rapid allocations - at least for inodes in
the same cylinder group. I think this was mentioned in the "Journaling
the ext2 filesystem" paper.
This could probably be faked by taking out any intelligence in block
allocation (allocate last block+1 or some such thing). Even as a mount
option (seq_alloc), this could be useful (for this type of streaming).
This will give you great write throughput, but if you don't read things
off the same way you read them - reading is going to suck.
I read in a discussion of multimedia filesystems (for PVRs) that a block
size of 256KB helped in throughput when playback configurations weren't
known (the more data you read before seeking the better). google for
"multimedia filesystems" - you'll find a fair few papers on such things.
Things like XFS were designed for large, high bandwidth systems, so
that's also worth looking into as a zero-effort approach :)
next prev parent reply other threads:[~2003-09-10 14:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-09 14:27 [ANNOUNCE] New hardware - SGA155D dual STM-1/OC3 PCI ad Horvath Gyorgy
2003-09-09 14:55 ` Alan Cox
2003-09-10 14:05 ` Stewart Smith [this message]
2003-09-09 19:15 ` Francois Romieu
-- strict thread matches above, loose matches on Subject: below --
2003-09-10 8:38 Horvath Gyorgy
2003-09-12 8:59 Horvath Gyorgy
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=1063202707.7632.25.camel@willster \
--to=stewart@linux.org.au \
--cc=HORVAATH@tmit.bme.hu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.