Hi
I heard linux does <= 32 page readahead from block devices
(scsi/ide/que?). Is there a way to double this? I want to read 256kB
chunks from the SCSI drives, as to get the best speed. These numbers are
based on some testing and information I've got from Compaq's storage guys.
roy
--
Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA
Computers are like air conditioners.
They stop working when you open Windows.
On Tue, 13 Nov 2001, Roy Sigurd Karlsbakk wrote:
> I heard linux does <= 32 page readahead from block devices
> (scsi/ide/que?). Is there a way to double this? I want to read 256kB
> chunks from the SCSI drives, as to get the best speed. These numbers are
> based on some testing and information I've got from Compaq's storage guys.
The -ac kernels have a way to tune this dynamically,
I guess we might want to push this change into 2.4
later on...
regards,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/
http://www.surriel.com/ http://distro.conectiva.com/
On Tue, Nov 13, 2001 at 01:55:42PM -0200, Rik van Riel wrote:
> On Tue, 13 Nov 2001, Roy Sigurd Karlsbakk wrote:
>
> > I heard linux does <= 32 page readahead from block devices
> > (scsi/ide/que?). Is there a way to double this? I want to read 256kB
> > chunks from the SCSI drives, as to get the best speed. These numbers are
> > based on some testing and information I've got from Compaq's storage guys.
>
> The -ac kernels have a way to tune this dynamically,
> I guess we might want to push this change into 2.4
> later on...
I got an other question related to this. I got a System with 7
Filesystems on LVM. One Filesystem contains only one file, a 10 GB
disk-image which is exported via ftp. Sometimes, 15 clients are
downloading the file at the same time. What would be theoretical the
best way to tune these downloads. It would be wise if linux would try to
read the file in big blocks to minimize seeking on the disk. The file is
usually only downloaded in one piece. So if a ftpd-process access the
file, I can be very sure that it will read the whole file. The best
would be if data is requested from the file if linux would read a block
of 256k data from the file before serving the next request from an other
process.
Thanks, for all the answers via pm, but I would like to explain a litte
bit more what I am looking for. I got this filesystem on lvm, and I want
my harddisk if there a several processes accessing the disk-image to go
to the position of process one, read 256k of data, go to the position of
process two, read 256k of data, go again to the position of the nex
process, read 256k of data and so one to minimize movement of the
harddisk-readhead.
And of course my problem is, that I want that only on this filesystem
(it is a reiserfs-filesystem) or logical volum. Not on the other
filesystems on this harddisk which contain normal data or swapspace
(this behaviour could cause a really ugly performance for swapspace)
The system is currently able to fully satisfy a 100 mbit
ethernetconnection, but I would like how I can get some extra
performance in such situations.
On Tuesday 13 November 2001 16:21, Roy Sigurd Karlsbakk wrote:
> Hi
>
> I heard linux does <= 32 page readahead from block devices
> (scsi/ide/que?). Is there a way to double this? I want to read 256kB
> chunks from the SCSI drives, as to get the best speed. These numbers are
> based on some testing and information I've got from Compaq's storage guys.
>
> roy
Note that the interface to /proc/ide/hdX/settings still is buggy...
i.e you should be able to do (in pages):
echo "file_readahead:64" > /proc/ide/hdX/settings
but the result will be a readahead of 128*1024 PAGES... and that
is too much... (even 1024 PAGES is too much)
(after patch, in kB)
echo "file_readahead:256" > /proc/ide/hdX/settings
It is likely that there are more settings in the ide subsystem that is
has this fault... (Andre, I keep repeating myself...)
/RogerL
--
Roger Larsson
Skellefte?
Sweden
> On Tuesday 13 November 2001 16:21, Roy Sigurd Karlsbakk wrote:
>> I heard linux does <= 32 page readahead from block devices
>> (scsi/ide/que?). Is there a way to double this?
Use blockdev --setra N /dev/foo for your favorite number N.
> Note that the interface to /proc/ide/hdX/settings still is buggy...
>
> i.e you should be able to do (in pages):
> echo "file_readahead:64" > /proc/ide/hdX/settings
> but the result will be a readahead of 128*1024 PAGES... and that
> is too much... (even 1024 PAGES is too much)
>
> (after patch, in kB)
> echo "file_readahead:256" > /proc/ide/hdX/settings
>
> It is likely that there are more settings in the ide subsystem that is
> has this fault... (Andre, I keep repeating myself...)
er...
I'm running Compaq RAID controllers... Not IDE...
--
Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA
Computers are like air conditioners.
They stop working when you open Windows.
On Wed, 14 Nov 2001, Roger Larsson wrote:
> On Tuesday 13 November 2001 16:21, Roy Sigurd Karlsbakk wrote:
> > Hi
> >
> > I heard linux does <= 32 page readahead from block devices
> > (scsi/ide/que?). Is there a way to double this? I want to read 256kB
> > chunks from the SCSI drives, as to get the best speed. These numbers are
> > based on some testing and information I've got from Compaq's storage guys.
> >
> > roy
>
> Note that the interface to /proc/ide/hdX/settings still is buggy...
>
> i.e you should be able to do (in pages):
> echo "file_readahead:64" > /proc/ide/hdX/settings
> but the result will be a readahead of 128*1024 PAGES... and that
> is too much... (even 1024 PAGES is too much)
>
> (after patch, in kB)
> echo "file_readahead:256" > /proc/ide/hdX/settings
>
> It is likely that there are more settings in the ide subsystem that is
> has this fault... (Andre, I keep repeating myself...)
>
> /RogerL
> --
> Roger Larsson
> Skellefte?
> Sweden
It is hard to reply when your ISP rotates/changes its total block of
assigned IP address, while still not being able to update or fix dns
records at netsol to operate correctly.
And if you set the value of any given settings value large than its top
boundary it would most likely wrap. Right now it appears that a readahead
patch that I was looking may have borked performance.
Regards,
Andre Hedrick
CEO/President, LAD Storage Consulting Group
Linux ATA Development
Linux Disk Certification Project
On Tue, Nov 13, 2001 at 10:01:39PM +0100, Erik Tews wrote:
> Thanks, for all the answers via pm, but I would like to explain a litte
> bit more what I am looking for. I got this filesystem on lvm, and I want
> my harddisk if there a several processes accessing the disk-image to go
> to the position of process one, read 256k of data, go to the position of
> process two, read 256k of data, go again to the position of the nex
> process, read 256k of data and so one to minimize movement of the
> harddisk-readhead.
>
At which level do you want the read ahead?
If you read ahead at the block level, you may not get data for the file you
want because of fragmentation. This is especially true with long running
Reiser file systems.
If you read ahead at the FS level, you could get even more seeking because
of fragmentation.
Also, you need enough memory to let the kernel hold the read ahead data long
enough to be used.
Mike
On Wed, Nov 14, 2001 at 12:26:20PM -0800, Mike Fedyk wrote:
> On Tue, Nov 13, 2001 at 10:01:39PM +0100, Erik Tews wrote:
> > Thanks, for all the answers via pm, but I would like to explain a litte
> > bit more what I am looking for. I got this filesystem on lvm, and I want
> > my harddisk if there a several processes accessing the disk-image to go
> > to the position of process one, read 256k of data, go to the position of
> > process two, read 256k of data, go again to the position of the nex
> > process, read 256k of data and so one to minimize movement of the
> > harddisk-readhead.
>
> At which level do you want the read ahead?
>
> If you read ahead at the block level, you may not get data for the file you
> want because of fragmentation. This is especially true with long running
> Reiser file systems.
I think fragmentation will be no problem, because this filesystem
contains only one file.
Readahead should be done on filesystem or block-level. Not on disklevel.
I can tune that with lvm, but I was not sure if a bigger readahead-value
is that what I want.
On Wed, Nov 14, 2001 at 09:41:22PM +0100, Erik Tews wrote:
> On Wed, Nov 14, 2001 at 12:26:20PM -0800, Mike Fedyk wrote:
> > At which level do you want the read ahead?
> >
> > If you read ahead at the block level, you may not get data for the file you
> > want because of fragmentation. This is especially true with long running
> > Reiser file systems.
>
> I think fragmentation will be no problem, because this filesystem
> contains only one file.
>
> Readahead should be done on filesystem or block-level. Not on disklevel.
> I can tune that with lvm, but I was not sure if a bigger readahead-value
> is that what I want.
Block and disk are conceptually the same in this instance because neither of
them know if the read ahead is going to get the next blocks for the file
being read or not...
In most cases, block=disk, except for lvm and raid...
Mike