8 Sep
2009
8 Sep
'09
5:32 a.m.
Ext3 or JFS
quite a strange question, imnsho :)
i'd rather ask about ext4 vs xfs
i would not recommend ext3 — too slow
xfs is fast & reliable, but at least it does not have any tools to
deal with bad blocks if they appear.
so the answer is ext4.
--
sex, bike, open source!
8 Sep
8 Sep
11:47 a.m.
New subject: Ext3 or JFS (or other) for linux audio?
On Tue, 8 Sep 2009, cunnilinux himself wrote:
Date: Tue, 8 Sep 2009 10:32:40 +0300
From: cunnilinux himself <cunnilinux(a)gmail.com>
To: linux-audio-user(a)lists.linuxaudio.org
Subject: Re: [LAU] Ext3 or JFS (or other) for linux audio?
I'm looking at this same question myself, but with one additional
constraint: Support on the Mac OSX platform - I frequently share my
projects with a collaborator who has one. A quick search turned up
several people who are just *beginning* to develop ext4 support for OSX.
--
Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
Ext3 or JFS
quite a strange question,
imnsho :)
i'd rather ask about ext4 vs xfs
i would not recommend ext3 — too slow
xfs is fast & reliable, but at least it does not have any tools to
deal with bad blocks if they appear.
so the answer is ext4.
8:04 p.m.
New subject: Ext3 or JFS (or other) for linux audio?
I'm looking at this same question myself, but
with one additional
constraint: Support on the Mac OSX platform - I frequently share my projects
with a collaborator who has one. A quick search turned up several people
who are just *beginning* to develop ext4 support for OSX.
so, there are three options for you:
(1) ext3 support implemented for mac os x
(2) hfs+ support implemented for linux
(3) ntfs-3g implemented for both (and windoze, naturally)
/* there is also fat, but it's not a filesystem at all :-D */
seems like you want the fastest option. unfortunately, i don't know which one.
--
sex, bike, open source!
10:47 p.m.
New subject: Ext3 or JFS (or other) for linux audio?
On Wed, Sep 09, 2009 at 01:04:11AM +0300, cunnilinux himself wrote:
I've recently had difficulties with hfs+. I used the debian
package hfsprogs, including fsck.hfsplus to manage an
external hfs+ formatted USB drive. The drive would
often get shut down in a "dirty" state, limiting me to
read-only access.
fsck.hfsplus -p would reset the "dirty" flag when it worked,
but it worked only intermittently. More often the process would
hang without releasing the device. This is with a recent
kernel and bleeding-edge (sid, unstable) debian
distribution.
I wouldn't be concerned about speed so much as being
interoperable.
I'm
looking at this same question myself, but with one additional
constraint: Support on the Mac OSX platform - I frequently share my projects
with a collaborator who has one. A quick search turned up several people
who are just *beginning* to develop ext4 support for OSX.
so, there are three options for you:
(1) ext3 support implemented for mac os x
(2) hfs+ support implemented for linux
(3) ntfs-3g implemented for both (and windoze, naturally)
/* there is also fat, but it's not a filesystem at all :-D */ seems like you want the fastest option. unfortunately,
i don't know which one.
--
sex, bike, open source!
--
Joel Roth
9 Sep
9 Sep
5:25 a.m.
New subject: Ext3 or JFS (or other) for linux audio?
I only see (1) as the most practical.
Or maybe hdparm -Tt $disk on one with ntfs-3g and other with ext3, look out
for any significant difference.
7:09 a.m.
New subject: Ext3 or JFS (or other) for linux audio?
On Wednesday 09 September 2009 09:25:28 Ray Rashif wrote:
Or maybe hdparm -Tt $disk on one with ntfs-3g and
other with ext3, look out
for any significant difference.
As far as I know hdparm tests are independent of the filesystem. At least here
I can also test directly on disks via /dev/sda or on unformatted disks...
If you want the performance of the filesystem, you have to run a real
benchmark.
Also, don't format one disk with ext3 and one with ntfs and compare these and
claim a "true" result. Because then you haven't compared ext3 with ntfs but
"ext3 on disk1" with "ntfs on disk2". Before saying anything about the
results, you have to also do "ext3 on disk2" and "ntfs on disk1".
Arnold
8:05 a.m.
New subject: Ext3 or JFS (or other) for linux audio?
2009/9/9 Arnold Krille <arnold(a)arnoldarts.de>
On Wednesday 09 September 2009 09:25:28 Ray Rashif
wrote:
No, you're right, hdparm is raw r/w and sees no FS. Slipped my mind for a
moment.
You can have one extra disk for this benchmark, and time operations on them.
Might want to follow http://www.debian-administration.org/articles/388 as
closely as possible, with the exception that you're comparing only two of
them. I might try this on an external disk, where the bottleneck is the
USB/interface speed, but FS differences can still be observed.
Or maybe hdparm -Tt $disk on one with ntfs-3g and
other with ext3, look
out
for any significant difference.
As far as I know hdparm tests are independent of the filesystem. At least
here
I can also test directly on disks via /dev/sda or on unformatted disks...
If you want the performance of the filesystem, you have to run a real
benchmark.
Also, don't format one disk with ext3 and one with ntfs and compare these
and
claim a "true" result. Because then you haven't compared ext3 with ntfs
but
"ext3 on disk1" with "ntfs on disk2". Before saying anything about
the
results, you have to also do "ext3 on disk2" and "ntfs on disk1".
Arnold
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
10:25 a.m.
New subject: Ext3 or JFS (or other) for linux audio?
On Wed, Sep 09, 2009 at 06:05:23PM +0800, Ray Rashif wrote:
No, you're right, hdparm is raw r/w and sees no
FS. Slipped my mind for a
moment.
Well ... you *might* create a big file on the filesystem, then use
losetup to bind it to a block device, and *then* use hdparm on that
loopback device. ;-)
Opinion ... I've never found any use for filesystem performance
measurement in audio applications ... it has never been the critical
path for me. As soon as the total data flow approaches the limit
imposed by the filesystem, then anything can cause a pause ... even a
disk drive thermal recalibration or a response to excessive vibration.
Such things cause a momentary delay, and if I'm trying to use the disk
the filesystem I'm using won't matter at all.
--
James Cameron
http://quozl.linux.org.au/
11:09 a.m.
New subject: Ext3 or JFS (or other) for linux audio?
On Wednesday 09 September 2009 14:25:17 James Cameron wrote:
On Wed, Sep 09, 2009 at 06:05:23PM +0800, Ray Rashif
wrote:
If file systems have problems with continuous reads from a continuous file.
Otherwise I really doubt that you will see something file-system specific.
BTW: Doing a real benchmark still requires one run with hdparm to get the
maximum values for the transfer rates...
No, you're right, hdparm is raw r/w and sees
no FS. Slipped my mind for a
moment.
Well ... you *might* create a big file on the filesystem, then use
losetup to bind it to a block device, and *then* use hdparm on that
loopback device. ;-) Opinion ... I've never found any use for
filesystem performance
measurement in audio applications ... it has never been the critical
path for me. As soon as the total data flow approaches the limit
imposed by the filesystem, then anything can cause a pause ... even a
disk drive thermal recalibration or a response to excessive vibration.
Such things cause a momentary delay, and if I'm trying to use the disk
the filesystem I'm using won't matter at all.
I think for plain recording it shouldn't make a difference. When playback
occurs, there are multiple files involved and it could be the seeks also depend
on how the file systems lays out the files on disk. So that might have an
influence. If this information isn't cached in ram.
Otherwise its just a matter of taste and bad experience. For example there are
three types of people regarding reiserfs: Those that haven't used it yet,
those that have used it and love it and finally those that had used it and lost
data because of it...
Arnold
10 Sep
10 Sep
1:45 a.m.
New subject: Ext3 or JFS (or other) for linux audio?
On Wed, Sep 09, 2009 at 03:08:58PM +0200, Arnold Krille wrote:
I think for plain recording it shouldn't make a
difference. When
playback occurs, there are multiple files involved and it could be the
seeks also depend on how the file systems lays out the files on disk.
So that might have an influence. If this information isn't cached in
ram.
Yes, the ideal is that the tracks being played are cached in RAM so that
no disk access is required. The recording track would be creating a
file that would be periodically written to disk.
(LWN handled something relevant to this today, in an article by Valerie,
subscriber only content at the moment but I imagine it will become free
in a couple of weeks from now ... http://lwn.net/Articles/351422/ ...
but the interesting thing there was that with ext3 and data=ordered,
data reaches disk within about five seconds by default ... and in the
previous article http://lwn.net/Articles/322823/ which is freely
available, is the mention of /proc/sys/vm/dirty_writeback_centisecs ...
for a multitrack studio scenario with backup power I'd increase this
value immediately prior to commencing the recording, so as to encourage
any writes to be buffered ... and restore it to default on transport
stop).
Actually, an even better ideal is to have a hard disk for each track,
and use a filesystem with delayed allocation ... this would minimise the
latency on the track read requests, and keep the disk heads sitting over
the area they will be next needed.
--
James Cameron
http://quozl.linux.org.au/
11 Sep
11 Sep
2:08 p.m.
New subject: Ext3 or JFS (or other) for linux audio?
On Wed, Sep 9, 2009 at 11:45 PM, James Cameron <quozl(a)us.netrek.org> wrote:
Yes, the ideal is that the tracks being played are
cached in RAM so that
no disk access is required. The recording track would be creating a
file that would be periodically written to disk.
this is not the ideal. its how any serious recording application has
to work. Linux filesystems can stall a thread for seconds while doing
disk i/o. you cannot do disk i/o from the thread that handles incoming
audio unless you already buffered like crazy.
ardour has a buffer of about 5 seconds, per channel, per direction
(its user configurable). both playback and recording occurs via these
buffers. ardour also tries to read/write in blocks of 256kB, since at
one point we empirically determined that this maximized disk
throughput in many cases. in an ideal world, we'd probably use O_RAW
for file i/o, and thus bypass the duplicated buffering of the kernel
FS buffer cache. but for now, that extra layer of buffering serves us
quite well (especially for read-ahead), and so we don't bother with
that.
5391
days inactive
5394
days old
linux-audio-user@lists.linuxaudio.org
11 comments
8 participants
participants (8)
-
Arnold Krille -
cunnilinux himself -
James Cameron -
Joel Roth -
Paul Davis -
Ray Rashif -
Rick Green -
Robert Persson