From owner-freebsd-scsi@FreeBSD.ORG Tue Jun 3 06:19:40 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EC1337B401 for ; Tue, 3 Jun 2003 06:19:40 -0700 (PDT) Received: from sift.mirapoint.com (sift.mirapoint.com [63.107.133.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id D141843FCB for ; Tue, 3 Jun 2003 06:19:39 -0700 (PDT) (envelope-from cer@mirapoint.com) Received: from alpo.mirapoint.com (alpo.mirapoint.com [63.107.133.20]) by sift.mirapoint.com (Mirapoint Messaging Server MOS 3.3.5-GR) with ESMTP id ABV00096; Tue, 3 Jun 2003 06:19:35 -0700 (PDT) Received: from 207.135.76.118 by alpo.mirapoint.com (Mirapoint Messaging Server MOS 3.3.5-GR) with HTTPS/1.1; Tue, 3 Jun 2003 06:19:35 -0700 Date: Tue, 3 Jun 2003 06:19:35 -0700 From: Carl Reisinger To: Kern Sibbald X-Mailer: Webmail Mirapoint Direct 3.3.5-GR MIME-Version: 1.0 Message-Id: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-scsi@freebsd.org Subject: Re: SCSI tape data loss X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cer@mirapoint.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2003 13:19:40 -0000 >Concerning the maximum buffer size: I have chosen >the default maximum buffer size to be 64512 bytes so >that it is smaller than 65536. In fact, 64512 bytes is >the size (126 blocks) that I used for tar in 1982 >and never had any problems. Try using the FreeBSD tar with the multi-volume flag (-M) and your record size. Without the flag the writes are page aligned, with the flag the writes are offset some, either 512 or 1536 bytes (I forget which), and the writes will be split by the kernel physio function into a 60K and 3K write. (This is with the tar shipped with FreeBSD up to at least 4.2. Later ones may also do this, I have not tried them) > >>From what I understand the 65536 point at which >buffers are always split only applies to devices in >fixed block mode, and probably older devices at that. This magic number has nothing to do with the device. I've only used variable block mode and newer technologies, SDLT, LTO. > >Though Bacula can run in fixed block mode, the >default is variable block, so I don't see that as >an issue here -- unless I am missing something? > >Can you explain why you mention 61440 bytes? and >why it might be a better choice than 64512? > 61440 was mentioned since that is the largest write that can be done without the physio function doing some surprising and annoying things to your write. 61440 is the size that, no matter its address alignment, can always be mapped with one page register. If you are careful to page align all writes then you can write up to 65536 and have one record sent to the tape device. (Actually, with a minor change to scsi_sa.c and limiting one self to newer SCSI HBAs you can go as high as 128KB for read/write) An example: Write 64512 bytes with a starting address of 4096. Physio will take this, see that the address is paged aligned, check that it can be mapped with one page register and perform one write. Now lets write 64512 bytes but with an address of 5632. In this case physio will notice it is not paged aligned and adjust the starting address to be 4096. Now 66048 bytes need to be mapped which exceeds the default size of 65536. In this case physio will map the first 60K (64K to him because of the starting address change), write that and then map and write the remainder. Now when one goes back to read 64512 bytes, the first read returns 61440 bytes and the second 3072 instead of just one read retuning 64512. >On aligning the buffers on a page boundary: interesting >idea, I'll look into it, but I'm not too keen on the >idea. > If your software has no problem with short reads and records being split into two, then don't bother page aligning. But, if you want to read exectly what you know you wrote then alignment is a must. Carl