Date: Thu, 4 Aug 2005 14:52:08 +0400 From: Andrey Chernov <ache@FreeBSD.ORG> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: Maxim.Sobolev@portaone.com, Dan Nelson <dnelson@allantgroup.com>, "current@freebsd.org" <current@FreeBSD.ORG> Subject: Re: Sub-optimal libc's read-ahead buffering behaviour Message-ID: <20050804105208.GA26150@nagual.pp.ru> In-Reply-To: <20050804104236.GC271@cirb503493.alcatel.com.au> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050804105208.GA26150>