From owner-freebsd-arch@FreeBSD.ORG Mon Oct 6 17:55:19 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E019C16A4B3; Mon, 6 Oct 2003 17:55:19 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 218EA43F85; Mon, 6 Oct 2003 17:55:19 -0700 (PDT) (envelope-from sam@errno.com) Received: from 66.127.85.91 ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h970tH0x012579 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 6 Oct 2003 17:55:18 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: "Poul-Henning Kamp" , Scott Long Date: Mon, 6 Oct 2003 17:53:28 -0700 User-Agent: KMail/1.5.2 References: <27374.1065481871@critter.freebsd.dk> In-Reply-To: <27374.1065481871@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310061753.28562.sam@errno.com> cc: arch@freebsd.org Subject: Re: Alignment of disk-I/O from userland. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2003 00:55:20 -0000 On Monday 06 October 2003 04:11 pm, Poul-Henning Kamp wrote: > In message <20031006163218.L55190@pooker.samsco.home>, Scott Long writes: ...stuff deleted... > >As for returning an error code for a buffer that we (arbitrarily) believe > >to be too big to align, [...] > > I have never advocated returning an error based on "alignment and size", > only based on alignment alone. Imposing this restriction is a major semantic change that I consider a very bad idea. You are basically imposing the semantics of O_DIRECT on all i/o operations going to a device. I think it is important to give best effort to support unaligned operations `by default. I can imagine restricting this to some upper size bound but existing applications, regardless of how well you consider them to be written, must continue to work. Sam