[vdr] Re: performance during cutting

["Rienecker, Fa. Evenio, ITS P, M" <C.Rienecker@deutschepost.de>]

That's right.
Have you ever done a 'find / -name foo.bar -print' on an ext2/ext3 fs ?
This'll take several minutes.
Since xfs stores this kind of information extremely efficient, the same command on an xfs fs takes less than a second.
xfs is optimized for many files on large partitions.

CU,
Christian.

> -----Original Message-----
> From: Matthias Weingart [mailto:matthias@pentax.boerde.de]
> Sent: Tuesday, March 26, 2002 8:25 PM
> To: vdr@linuxtv.org
> Subject: [vdr] Re: performance during cutting
> 
> 
> On Tue, Mar 26, 2002 at 04:34:37PM +0100, Emil Naepflein wrote:
> > On Tue, 26 Mar 2002 12:16:47 +0100 (MET), thees@informatik.uni-kl.de
> > wrote:
> > 
> > > I already tried to slow down the thread by inserting 
> > > usleep()-calls with several times, 
> > 
> > I have also added usleep calls into the cutting thread 
> until the cutting
> > rate was not more than about 3 MB/s. With this the response time and
> > cutting time is acceptable.
> 
> I had similar problems with reiser-fs before (from suse 2.4.0 kernel).
> I reduced the "read ahead" value in /proc, and it worked much better.
> But after using XFS I never had that problems, I do not have to
> change readahead... I am very happy with XFS (Kernel 2.4.17) it
> is performing much better under high load.
> 
> This is my /etc/init.d/boot.local file now:
> 
> #echo "file_readahead:80" >> /proc/ide/hda/settings
> #echo "file_readahead:80" >> /proc/ide/hdb/settings
> /sbin/hdparm -c 3 /dev/hda
> /sbin/hdparm -c 3 /dev/hdb
> 
>         Matthias
> 
>