From owner-freebsd-current@FreeBSD.ORG Thu Aug 4 10:52:15 2005 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FBCD16A41F for ; Thu, 4 Aug 2005 10:52:15 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 639E243D4C for ; Thu, 4 Aug 2005 10:52:14 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.4/8.13.4) with ESMTP id j74Aq8Rj026245; Thu, 4 Aug 2005 14:52:08 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.4/8.13.4/Submit) id j74Aq8ne026244; Thu, 4 Aug 2005 14:52:08 +0400 (MSD) (envelope-from ache) Date: Thu, 4 Aug 2005 14:52:08 +0400 From: Andrey Chernov To: Peter Jeremy Message-ID: <20050804105208.GA26150@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Peter Jeremy , Maxim.Sobolev@portaone.com, Dan Nelson , "current@freebsd.org" References: <42F0CCD5.9090200@portaone.com> <20050803150117.GD93405@dan.emsphone.com> <42F0E9B2.9080208@portaone.com> <20050804060251.GA21228@nagual.pp.ru> <20050804063908.GA21871@nagual.pp.ru> <20050804075711.GB271@cirb503493.alcatel.com.au> <20050804082527.GA22992@nagual.pp.ru> <20050804104236.GC271@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050804104236.GC271@cirb503493.alcatel.com.au> User-Agent: Mutt/1.5.9i Cc: Maxim.Sobolev@portaone.com, Dan Nelson , "current@freebsd.org" Subject: Re: Sub-optimal libc's read-ahead buffering behaviour X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2005 10:52:15 -0000 On Thu, Aug 04, 2005 at 08:42:36PM +1000, Peter Jeremy wrote: > Consider /dev/mem (since that is a favourite in this thread). You are > unlikely to hit EOF but reading more than required is likely to cause > unwanted I/O errors or unexpected device behaviour by accidently reading > "magic" device addresses. > > That said, most other devices will either reject seeks (eg tapes) > or will correctly (if inefficiently) handle reading too much. And > anyone who uses stdio to read /dev/mem probably deserves the hole > in their foot. > > I can see two reasonable interpretations of stdio on devices: > 1) The process issues a setbuf(3) family call to define the buffer size > that it wants to use for physical reads/writes. The process then uses > stdio calls to read/write arbitrary sized data which is re-blocked by > stdio to suit the device. Yes. See my other answer in this thread. Buffering or no-buffering or sized-buffering is well controled via setvbuf and is a part of user interface. If user don't use specifical setvbuf on chardev, he probably assume that this particular chardev is bufffer-friendly. But there is no similar user-visible knob to turn on/off fseek's in-buffer seeking, so it is always off for chardev for more safety. > 2) stdio should be transparent - fread/fwrite/fseek are expected to > map directly onto read/write/lseek. It is never do that way per desing. > The current implementation falls somewhere in between: read and write > are buffered but seeks are transparent. This would seem to be the worst Seeks are just not controlled by user, so they are transparent for that reason, while read/write buffering is controlled. > In both cases above, seek really needs to be intelligent - more so > than for regular files. It needs to lseek() in multiples of the > device block size and then adjust the buffer offset to handle any > remainder. I don't understand this statement well enough. Currently fseek always sense in-buffer data for regular files for both SEEK_SET and SEEK_CUR. -- http://ache.pp.ru/