I have a real picky tape drive (DLT series) that likes to be fed large chunks
of data at once, otherwise after every 2-4KB of data it halts and rewinds
itself because its cache for writing to the tape is empty.
My best solution to this problem was to use 'tar -b 4096', which sends 4096 x
512-byte blocks at once for a total of a 2MB buffer size. This worked fine for
several weeks, until 2 days ago I got this message (and the backup fails):
st: failed to enlarge buffer to 2097152 bytes.
Free memory shows:
total used free shared buffers cached
Mem: 517036 514468 2568 751908 47804 189488
-/+ buffers/cache: 277176 239860
Swap: 136544 452 136092
Unfortunately, all of the "free" memory right now is eaten up using cache. Is
there a way I can just tell the kernel to allocate memory from the cache for
the buffer? I'm sure there's gotta be a 2MB-sized chunk in that 189MB cache
-somewhere-.
Why doesn't the kernel's get_free_pages() function support moving data around
in memory to get larger chunks for what it needs? I see this same problem
happening in SVGATextMode where allocating space for a NxM character screen
(where NxM >= 16384) fails because there is no contiguous memory space. I think
at least it should be able to use some cache.
Suggestions?
-Byron
--
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [email protected]
On Thu, 15 Mar 2001, Byron Stanoszek wrote:
> I have a real picky tape drive (DLT series) that likes to be fed large chunks
> of data at once, otherwise after every 2-4KB of data it halts and rewinds
> itself because its cache for writing to the tape is empty.
>
> My best solution to this problem was to use 'tar -b 4096', which sends 4096 x
> 512-byte blocks at once for a total of a 2MB buffer size. This worked fine for
> several weeks, until 2 days ago I got this message (and the backup fails):
>
> st: failed to enlarge buffer to 2097152 bytes.
>
Look at ../linux/drivers/scsi/st_options.h .
You might want to set ST_MAX_BUFFERS to a higher value. This wastes
some memory when the driver is not in-use, but you can reduce the
tendency to need to allocate more space at run-time.
You can also lower the ST_WRITE_THRESHOLD.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
On Thu, 15 Mar 2001, Byron Stanoszek wrote:
> I have a real picky tape drive (DLT series) that likes to be fed large chunks
> of data at once, otherwise after every 2-4KB of data it halts and rewinds
> itself because its cache for writing to the tape is empty.
>
> My best solution to this problem was to use 'tar -b 4096', which sends 4096 x
> 512-byte blocks at once for a total of a 2MB buffer size. This worked fine for
> several weeks, until 2 days ago I got this message (and the backup fails):
>
> st: failed to enlarge buffer to 2097152 bytes.
>
The default maximum number of scatter/gather segments in the tape driver
is 16. This means that big chunks of memory are needed to allocate a 2 MB
buffer. You can increase the number of segments up to, e.g., 128. This
means that only 16 kB chunks are needed to make up a 2 MB buffer. The
number of scatter/gather segments is also limited by your SCSI adapter
driver. Note that even with 16 kB segments you may find problems at
some time because multi-page allocations are needed.
You can increase the number of scatter/gather segments at system
startup/module loading or when compiling the driver. See the file
linux/drivers/scsi/README.st for the syntax and st_options.h for the
compile-time definition.
Kai