28 Jun
2011
28 Jun
'11
12:45 a.m.
Hello, all,
I know this topic comes up now and again. I'm about to create a
partition for audio work and am wondering whether any new consensus has
been reached over which is the best file system format for the job. What
are you, fellows using?
Cheers,
S.M.
--
--
28 Jun
28 Jun
9:33 a.m.
On Tuesday 28 June 2011 00.47.13 S. Massy wrote:
Hello, all,
I know this topic comes up now and again. I'm about to create a
partition for audio work and am wondering whether any new consensus has
been reached over which is the best file system format for the job. What
are you, fellows using?
I have used xfs for audio partitions the last two-three years now and I don't
have any issues so far. xfs is known to bee good when dealing with big files.
Another thing is that it is not very sensitive for fragmentations problems but
you can still defragment the partition if you want to. You can do a lot of
other stuff too, such as dumping and restoring (for backup) without unmounting
the partition first. More info here: http://en.wikipedia.org/wiki/XFS .
Jostein
29 Jun
29 Jun
7:57 p.m.
I guess I got the answer to my main question: there isn't any consensus. :)
Thanks to all who responded, your input was all very valuable.
Cheers,
S.M.
--
28 Jun
28 Jun
9:34 p.m.
I've been using ext3. Works well for me!
AKJ
On Mon, Jun 27, 2011 at 5:47 PM, S. Massy <lists(a)wolfdream.ca> wrote:
Hello, all,
I know this topic comes up now and again. I'm about to create a
partition for audio work and am wondering whether any new consensus has
been reached over which is the best file system format for the job. What
are you, fellows using?
Cheers,
S.M.
--
--
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org
29 Jun
29 Jun
1:40 a.m.
On Monday, June 27, 2011 05:47:13 pm S. Massy wrote:
Hello, all,
I know this topic comes up now and again. I'm about to
create a partition for audio work and am wondering
whether any new consensus has been reached over which is
the best file system format for the job. What are you,
fellows using?
Something like this should do you good:
- For hard disk recording... use a NON-journaling
file system like ext2. (E.g. mounted as
/tmp or something.) This removes the overhead
of updating the journal for each transaction
to the disk. If you have a power failure during
a recording, you're pretty fsck'd no matter which
way you go... so the journal won't help you.
- For everything else... use a stable, journaling
filesystem. ext4 is very nice, as is ext3.
But things like xfs, reiserfs, jfs, etc... these
are all good choices. I do *not* recommend
btrfs right now. I've encountered too many
problems with it to recommend it as a stable fs.
I think I first encountered this idea from the ardour docs.
-gabriel
1:49 a.m.
-------- Original Message --------
Subject: Re: [LAU] Best file system for audio?
From: Gabriel M. Beddingfield <gabrbedd(a)gmail.com>
To: linux-audio-user(a)lists.linuxaudio.org, lists(a)wolfdream.ca
Date: 06/28/2011 05:40 PM
On Monday, June 27, 2011 05:47:13 pm S. Massy wrote:
What type of performance hit
does journalized file systems take?
Does a non-journalized file system give you less latency?
Hello, all,
I know this topic comes up now and again. I'm about to
create a partition for audio work and am wondering
whether any new consensus has been reached over which is
the best file system format for the job. What are you,
fellows using?
Something like this should do you good:
- For hard disk recording... use a NON-journaling
file system like ext2. (E.g. mounted as
/tmp or something.) This removes the overhead
of updating the journal for each transaction
to the disk. If you have a power failure during
a recording, you're pretty fsck'd no matter which
way you go... so the journal won't help you. - For everything else... use a stable, journaling
filesystem. ext4 is very nice, as is ext3.
But things like xfs, reiserfs, jfs, etc... these
are all good choices. I do *not* recommend
btrfs right now. I've encountered too many
problems with it to recommend it as a stable fs.
I think I first encountered this idea from the ardour docs.
-gabriel
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
Christopher Cherrett
ccherrett(a)openoctave.org
http://www.openoctave.org
4:07 a.m.
On Tuesday, June 28, 2011 06:49:24 pm Christopher Cherrett
wrote:
Here's the simplified concept of a journaling file system.
For each chunk of data that will be written to the disk, the
procedure is something like:
1. Add a log entry in the journal that you are going
to replace data at location A with data at
location B.
2. Write the data for location B.
3. Point the file system to location B instead of A.
4. Delete the log entry from the journal.
While this generally happens pretty fast... chances are that
the journal, location A, and location B are in 3 totally
different locations. That means that the your disk will
seek each time. This lowers your throughput/bandwidth.
When recording (i.e. large, sequential files) on a non-
journaling file system... you simply do step 2. Over and
over. And you don't have to seek. This improves your write
performance. But since you're not journaling, an unexpected
power outage can result in a total filesystem corruption
(but it's usually just a localized filesystem corruption).
With that said, I've never had a problem recording on a
journaling filesystem... but the original question was "what
is the best?"
- For hard
disk recording... use a NON-journaling
file system like ext2. (E.g. mounted as
/tmp or something.) This removes the overhead
of updating the journal for each transaction
to the disk. If you have a power failure during
a recording, you're pretty fsck'd no matter which
way you go... so the journal won't help you.
What type of performance hit does journalized file
systems take?
Does a non-journalized file system give you less
latency?
No. It give you more hard drive bandwidth and more CPU
headroom.
Your hard disk performance has nothing to do with audio
latency.
-gabriel
5:04 a.m.
On Tue, Jun 28, 2011 at 9:07 PM, Gabriel M. Beddingfield
<gabrbedd(a)gmail.com> wrote:
On Tuesday, June 28, 2011 06:49:24 pm Christopher
Cherrett
wrote:
Here's the simplified concept of a journaling file system.
For each chunk of data that will be written to the disk, the
procedure is something like:
1. Add a log entry in the journal that you are going
to replace data at location A with data at
location B.
2. Write the data for location B.
3. Point the file system to location B instead of A.
4. Delete the log entry from the journal.
That is not how it is (usually) implemented.
- For
hard disk recording... use a NON-journaling
file system like ext2. (E.g. mounted as
/tmp or something.) This removes the overhead
of updating the journal for each transaction
to the disk. If you have a power failure during
a recording, you're pretty fsck'd no matter which
way you go... so the journal won't help you.
What type of performance hit does journalized file
systems take?
While this generally happens pretty fast... chances
are that
the journal, location A, and location B are in 3 totally
different locations. That means that the your disk will
seek each time. This lowers your throughput/bandwidth.
A good journalled file system should perform at least as well. The log
is written sequentially and the data pages usually need not be written
synchronously.
There are many huge variables, of course. Writing the log to a
different device can help a lot. Etc. etc.
When recording (i.e. large, sequential files) on a
non-
journaling file system... you simply do step 2. Over and
over. And you don't have to seek. This improves your write
performance. But since you're not journaling, an unexpected
power outage can result in a total filesystem corruption
(but it's usually just a localized filesystem corruption).
With that said, I've never had a problem recording on a
journaling filesystem... but the original question was "what
is the best?"
The only way to really answer any of these questions is with realistic
benchmark comparisons (not easy to do well).
--
joq
Does a non-journalized file system give you less
latency?
No. It give you more hard drive bandwidth and more CPU
headroom.
Your hard disk performance has nothing to do with audio
latency. 
8:02 a.m.
On Wednesday 29 June 2011 01:40:24 Gabriel M. Beddingfield wrote:
On Monday, June 27, 2011 05:47:13 pm S. Massy wrote:
I don't believe the journal takes that much overhead. What makes recording
more difficult is that with one ardour-session and several channels, you are
writing several files at once. So you want a disk with fast seek-time and/or
high latencies set in jack/ardour. And if you want to optimize the disk, you
will take a serious look at ssd for the recording of the current session and
hold the archive on a nas with raid.
If you are just recording (no playback of existing material) you can further
optimize by using an app that records your several channels into one file
(which is written sequentially) like timemachine and the likes.
Wether you use ext[234], xfs or anything else doesn't matter. All current
filesystems can be resized at least offline, so putting your partitions in a lvm
is a good idea even if you are on a laptop.
I know this topic comes up now and again. I'm
about to
create a partition for audio work and am wondering
whether any new consensus has been reached over which is
the best file system format for the job. What are you,
fellows using?
Something like this should do you good:
- For hard disk recording... use a NON-journaling
file system like ext2. (E.g. mounted as
/tmp or something.) This removes the overhead
of updating the journal for each transaction
to the disk. If you have a power failure during
a recording, you're pretty fsck'd no matter which
way you go... so the journal won't help you. - For everything else... use a stable, journaling
filesystem. ext4 is very nice, as is ext3.
But things like xfs, reiserfs, jfs, etc... these
are all good choices.
'reiserfs' and 'stable' in the same sentence:-/
Well, there are two types of people regarding reiserfs, those who love it and
those who lost data using reiserfs...
Have fun,
Arnold
8:16 a.m.
On 06/29/2011 08:02 AM, Arnold Krille wrote:
I don't believe the journal takes that much
overhead. What makes recording
more difficult is that with one ardour-session and several channels, you are
writing several files at once. So you want a disk with fast seek-time and/or
high latencies set in jack/ardour.
i found that increasing ardour's disk buffer size from 5 seconds to
something like 45 seconds helps a lot. basically, you throw ram at the
problem :) since i did that, i've never seen the dreaded "disk couldn't
keep up with ardour" message again.
you will want to undo this during editing, though, or else ardour will
try to fill those buffers before playing, which takes time.
iiuc ardour3 allows you to set different read and write buffers, which
eliminates the need to change settings. but i haven't tested that in
production yet.
And if you want to optimize the disk, you
will take a serious look at ssd for the recording of the current session and
hold the archive on a nas with raid.
not sure about ssd - i think that's wasteful given the limited number of
r/w cycles you get from those things. but raid1 is pretty much a must
for what i do. i can't imagine discussing accidental data loss due to
single drive failure with a customer...
especially not if it's a choir and orchestra whose combined salary would
easily buy you a multi-TB RAID6 per hour.
everything goes to raid1 when i do recording jobs, and before the
machine is moved, i make a backup copy to an external disk that is
looked after very, very well.
9:15 a.m.
Hi,
On Wednesday 29 June 2011 08:16:36 Jörn Nettingsmeier wrote:
Well, "limited" in the sense that manufacturers and admins are pushing to use
them for database-servers, lots of rw-access, lots of random-access. And thats
where their main advantage is. As a bonus you get less power consumption, less
heat and less mechanical vibrations and noise (which is good for the other
hdds in the server).
On 06/29/2011 08:02 AM, Arnold Krille wrote:
That is something good for the archives. And maybe for some wiki or FAQ on the
ardour page, I think...
I don't believe the journal takes that much
overhead. What makes
recording more difficult is that with one ardour-session and several
channels, you are writing several files at once. So you want a disk with
fast seek-time and/or high latencies set in jack/ardour.
i found that increasing
ardour's disk buffer size from 5 seconds to
something like 45 seconds helps a lot. basically, you throw ram at the
problem :) since i did that, i've never seen the dreaded "disk couldn't
keep up with ardour" message again.
you will want to undo this during editing, though, or else ardour will
try to fill those buffers before playing, which takes time. And if you
want to optimize the disk, you
will take a serious look at ssd for the recording of the current session
and hold the archive on a nas with raid.
not sure about ssd - i think that's
wasteful given the limited number of
r/w cycles you get from those things. but raid1 is pretty much a must
for what i do. i can't imagine discussing accidental data loss due to
single drive failure with a customer...
especially not if it's a choir and orchestra whose combined salary would
easily buy you a multi-TB RAID6 per hour.
everything goes to raid1 when i do recording jobs, and before the
machine is moved, i make a backup copy to an external disk that is
looked after very, very well.
Too bad that most venues have slow connections, otherwise one could sync an
encrypted copy to amazons S3 or stratos HiDrive for security... But imagine
pushing a 2GB recording-session over a HDSPA+ connection that is limited to
64kbit/s after the first GB:-)
Have fun,
Arnold
9:42 a.m.
2011/6/29 Arnold Krille <arnold(a)arnoldarts.de>de>:
'reiserfs' and 'stable' in the same sentence:-/
Well, there are two types of people regarding reiserfs, those who love it and
those who lost data using reiserfs...
For me, reiserfs appeared stable, but after some time,
when the disk grew, (initial) disk access became slower and slower.
I've not experienced that with ext3/ext4 so far.
--
E.R.
7:46 a.m.
On 06/28/2011 12:47 AM, S. Massy wrote:
Hello, all,
I know this topic comes up now and again. I'm about to create a
partition for audio work and am wondering whether any new consensus has
been reached over which is the best file system format for the job. What
are you, fellows using?
Cheers,
S.M.
Ext3 with the noatime parameter. There's also this modified inotify
max_user_watches setting lingering around on the webs
(fs.inotify.max_user_watches = 524288) that might somehow yield better
performance but I haven't got that cleared out so maybe someone could
shed a light on that?
Best,
Jeremy
3 Jul
3 Jul
11:34 a.m.
On 06/29/2011 07:46 AM, Jeremy Jongepier wrote:
There's also this modified inotify
max_user_watches setting lingering
around on the webs (fs.inotify.max_user_watches = 524288) that might
somehow yield better performance but I haven't got that cleared out so
maybe someone could shed a light on that?
No one? Then I guess this setting is bogus :)
Best,
Jeremy
4827
days inactive
4833
days old
linux-audio-user@lists.linuxaudio.org
13 comments
10 participants
participants (10)
-
Aaron Krister Johnson -
Arnold Krille -
Christopher Cherrett -
Emanuel Rumpf -
Gabriel M. Beddingfield -
Jack O'Quin -
Jeremy Jongepier -
Jostein Chr. Andersen -
Jörn Nettingsmeier -
S. Massy