I'm trying to write a LOT (1 gig) of data to disk AFAP. The disk is not
busy for any other I/O at all.
What Linux is doing as this data is being written is filling up RAM with
all the buffers. That would be good if the amount of buffering was
reasonable. Instead if immediately fills up all free and stealable pages
from RAM. Then the process doing the writing finally blocks with RAM
nearly full. Of course now pages are being written, but some of the pages
being written are those of other processes that really don't need to be
written out because they are going to have to be read back in real soon.
I don't need 24 meg of buffer space for one disk, even if I were writing
it at random, though in this case I am writing sequentially. 1 or 2 meg
might be fine.
What I am looking for is some way to control the amount of I/O buffer pages
used in RAM, either total RAM usable for buffers, or per process.
One solution is to make the program write a little then fsync() or close()
and re- open(). But that just makes things work on a stop-and-go basis,
which is also not a good solution.
What I'd most like to have is to have the process doing the writing to
block until buffer space is again available within the quota for buffers.
Thus I could sustain a continuous stream of data flow, and still have some
buffered data to allow reasonable seek-elevator optimizing in random cases.
I'm looking for what kernel tuning settings might be usable for this (I did
not find any that obviously stood out in the source), or maybe ioctl() or
fcntl() operations that I could at least do this setting per device or fd.
If nothing else can be done, I'm also devising some bizarre methods to get
around it. One is to use a rotating set of child processes that each do
some I/O then fsync(). I just hope the fsync() on a fd open to several
processes still allows the other processes to keep running, so I can keep
at least a certain small amount of data buffered to keep the disk going
at full speed.
I want this to also apply to tape. I have both IDE and SCSI disk, and SCSI
tape. One tape drive is a QIC-150 and I like to keep it fully streaming,
and when Linux gets into thrashing with the overbuffering, it often fails
to sustain I/O.
There are other problems associated with "buffer glut", so I am getting
really anxious to find a solution to this.
Phil Howard KA9WGN +-------------------------------------------------------+
Linux Consultant | Linux installation, configuration, administration, |
Milepost Services | monitoring, maintenance, and diagnostic services. |