From owner-freebsd-scsi@FreeBSD.ORG Mon Jun 2 15:42:45 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 A706237B401 for ; Mon, 2 Jun 2003 15:42:45 -0700 (PDT) Received: from sift.mirapoint.com (sift.mirapoint.com [63.107.133.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD0D543F3F for ; Mon, 2 Jun 2003 15:42:42 -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 ABU95230; Mon, 2 Jun 2003 15:42:35 -0700 (PDT) Received: from 192.168.10.83 by alpo.mirapoint.com (Mirapoint Messaging Server MOS 3.3.5-GR) with HTTPS/1.1; Mon, 2 Jun 2003 15:42:35 -0700 Date: Mon, 2 Jun 2003 15:42: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: Mon, 02 Jun 2003 22:42:46 -0000 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. >