Veritas-bu

[Veritas-bu] Buffered Writes and DLT7000

2002-04-02 23:18:36
Subject: [Veritas-bu] Buffered Writes and DLT7000
From: peter.urbanec AT csfb DOT com (Urbanec, Peter)
Date: Wed, 3 Apr 2002 12:18:36 +0800
> The "tape-driver-buffering" parameter is set to the number of write
> requests to buffer. If not set, the man page says it defaults to 0.
> Wouldn't setting the limit on the number of write requests to buffer
> to zero effectively disable write buffering?

Not necessarily. If turning on buffering also enables asynchronous
returns from the driver, then having a 0 value for a buffer queue
would be different to a blocking write call that does not return
until the buffer has been written out to tape or drive buffer.

> The st man page goes on to state that if write buffering is to
> operate properly sufficient space must exist on the media after
> LEOT in order to flush the remaining data to tape. How much media
> space is left when DLT7K signals LEOT?

If I recall correctly, the SCSI-2 spec recommends that a device does
not buffer more data than it can deal with at EOT. The drive buffer
capacity is likely to be tuned for worst case scenario, however the
drive is under no obligation to accept further data from the host.

If you want to be ultra safe and do not know how the device driver
and application deal with error recovery, turn off driver level
buffering and let the drive and application do it.

Given decent asynchronous / multi-threaded application design,
buffering at the device driver level is not going to bring much
and may even slow you down if you end up performing excessive data
copying.

I have written a number of device drivers for modern operating
systems, including SCSI-2 tape drivers. Buffering data in a SCSI
device driver is a bad idea. Decent application design will give
you much better performance improvements than trying to cover up
in the device driver. Keeping the device drivers simple and
predictable not only improves the stability of the system, but
aids the application developer in correct driver usage and more
consistent handling of error recovery.

I have not had a chance to examine NBU code, but based on the
discussion of bptm and shared memory, I would suspect that the
application is designed to buffer data and is likely to do the
right thing. NBU does not do any clever error recovery, like check
pointing, but it will go to some effort to not lose data.

Cheers,

        Peter Urbanec    B.Sc.(Comp.Sci.)  UNSW
        mailto:peter.urbanec AT csfb DOT com

This message is for the named person's use only. It may contain sensitive and 
private proprietary or legally privileged information. No confidentiality or 
privilege is waived or lost by any mistransmission. If you are not the intended 
recipient, please immediately delete it and all copies of it from your system, 
destroy any hard copies of it and notify the sender. You must not, directly or 
indirectly, use, disclose, distribute, print, or copy any part of this message 
if you are not the intended recipient. CREDIT SUISSE GROUP and each legal 
entity in the CREDIT SUISSE FIRST BOSTON or CREDIT SUISSE ASSET MANAGEMENT 
business units of CREDIT SUISSE FIRST BOSTON reserve the right to monitor all 
e-mail communications through its networks. Any views expressed in this message 
are those of the individual sender, except where the message states otherwise 
and the sender is authorized to state them to be the views of any such entity.
Unless otherwise stated, any pricing information given in this message is 
indicative only, is subject to change and does not constitute an offer to deal 
at any price quoted. Any reference to the terms of executed transactions should 
be treated as  preliminary only and subject to our formal written confirmation.



<Prev in Thread] Current Thread [Next in Thread>
  • [Veritas-bu] Buffered Writes and DLT7000, Urbanec, Peter <=