From owner-freebsd-scsi@FreeBSD.ORG Tue Jun 3 07:01:58 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 C58B137B401 for ; Tue, 3 Jun 2003 07:01:58 -0700 (PDT) Received: from sift.mirapoint.com (sift.mirapoint.com [63.107.133.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0146043F93 for ; Tue, 3 Jun 2003 07:01:58 -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 ABV00329; Tue, 3 Jun 2003 07:01:53 -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 07:01:53 -0700 Date: Tue, 3 Jun 2003 07:01:53 -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 14:01:59 -0000 > >- When using tar (or say Bacula), how do you know > your writes are split by the kernel? One of my pet peeves, you don't know. Physio just blindly does this, which I believe is fine for a disk but can be quite annoying when applied to a tape device. Makes me wish for a physio that works like the USG and Research V7 versions which would just fail the write if it could not perform it in one shot (showing my age here). In the case > of Bacula, with the buffer size I use, it ALWAYS > gets back exactly what it wrote. From my userland > perspective I see no double writes. Then, so far, your buffers have been correcty aligned. If you use malloc they will be (check the malloc man page, this is mentioned in the first paragraph). > >- What is the "page" that you are referring to? > Paged memory? If I am not mistaken the page > size can be radically different depending on the > OS and hardware. I.e. 1024 to 4096 or even more. > Here's where I fall down. The page register I keep mentioning is the x86 MMU registers, I really do not know their proper name in the x86 world. One register can map up 64K but must be page (4096 byte) aligned. >- How does one determine what a page size is, > preferably in a system independent way? > I don't know how widespread this is, but check out getpagesize(3). If you count system include headers as system independent then PAGE_SIZE can be used (it's in param.h). If you start messing around with the max write size then DFLTPHYS can be used as the limit. Carl