Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

From: ross
Date: Thu Jan 20 2005 - 12:58:47 EST


On Thu, Jan 20, 2005 at 10:42:24AM -0500, Paul Davis wrote:
> over on #ardour last week, we saw appalling performance from
> reiserfs. a 120GB filesystem with 11GB of space failed to be able to
> deliver enough read/write speed to keep up with a 16 track
> session. When the filesystem was cleared to provide 36GB of space,
> things improved. The actual recording takes place using writes of
> 256kB, and no more than a few hundred MB was being written during the
> failed tests.

It's been a long while since I followed ReiserFS development closely,
*however*, this issue used to be a common problem ReiserFS - when
free space starts to drop below 10%, performace takes a big hit. So
performance improved when space was cleared up.

I don't remember what causes this or what the status is in modern
ResierFS systems.

> everything i read about reiser suggests it is unsuitable for audio
> work: it is optimized around the common case of filesystems with many
> small files. the filesystems where we record audio is typically filled
> with a relatively small number of very, very large files.

Anecdotally, I've found this to not be the case. I only use ReiserFS
and have a few reasonably sized projects in Ardour that work fine:
maybe 20 tracks, with 10-15 plugins (in the whole project), and I can
do overdubs with no problems. It may be relevant that I only have a
four track card and so load is too small.

But at least in my practice, it hasn't been a huge hinderance.

--
Ross Vandegrift
ross@xxxxxxxxxxxx

"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/