From owner-freebsd-scsi@FreeBSD.ORG Tue Jun 3 00:28:49 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 5DD8937B401 for ; Tue, 3 Jun 2003 00:28:49 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE29B43FBD for ; Tue, 3 Jun 2003 00:28:47 -0700 (PDT) (envelope-from kern@sibbald.com) Received: from [192.168.68.112] (rufus [192.168.68.112]) by matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h537Sbv08582; Tue, 3 Jun 2003 09:28:38 +0200 From: Kern Sibbald To: cer@mirapoint.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1054625317.13630.68.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jun 2003 09:28:37 +0200 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 List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2003 07:28:49 -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. >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. 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? On aligning the buffers on a page boundary: interesting idea, I'll look into it, but I'm not too keen on the idea. Best regards, Kern On Tue, 2003-06-03 at 00:42, Carl Reisinger wrote: > While your current problem may not be related to the > tendency of physio to silently breakup writes (and reads) I > believe you should revisit your code and make sure all buffers > are on a page boundary, especially since your writes are over > 61440 bytes in size. And the max bufer size should be limited > to 65536 (otherwise all writes will be split). > > Doing this now will prevent surprises in the future. > > Carl Reisinger > Mirapoint > > > > >Most of Bacula writes are 64512 bytes, and all the > >data that was lost consisted of blocks of 64512 bytes. > > > >> > >> But I sorta doubt that this was the issue. > >> > >> A buddy of mine at Mirapoint did just remind me that physio > can silently > >> break up xfers that are even less than 64k if the buffer > isn't page > >> aligned- I'd forgotten about that. But I'm not sure that > this is what is > >> occurring. > > > >The buffers are 64 bit aligned but not page aligned. > >