From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 20 12:40:34 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 4017B1065689; Sun, 20 Nov 2011 12:40:34 +0000 (UTC) Date: Sun, 20 Nov 2011 12:40:34 +0000 From: Alexander Best To: Tim Kientzle Message-ID: <20111120124034.GA54811@freebsd.org> References: <20111115202450.GA73512@freebsd.org> <20111116102239.GA2687@britannica.bec.de> <20111116131428.GA40723@freebsd.org> <20111116232152.GC21793@britannica.bec.de> <20111117002438.GA55931@freebsd.org> <201111172055.pAHKtZso061118@triton8.kn-bremen.de> <20111118203122.GA9508@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org, Juergen Lock Subject: Re: easy way to determine if a stream or fd is seekable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 12:40:34 -0000 On Sat Nov 19 11, Tim Kientzle wrote: > > On Nov 18, 2011, at 12:31 PM, Alexander Best wrote: > > > On Fri Nov 18 11, Tim Kientzle wrote: > >> > >> Take a look at > >> > >> http://libarchive.googlecode.com/svn/trunk/libarchive/archive_read_open_filename.c > >> > >> Especially the comments about detecting "disk-like" devices. > >> I rewrote a bunch of this code to introduce an explicit > >> notion of "strategy" so that we could optimize access > >> to a variety of different devices. > >> > >> This code has a notion of "disk-like" file descriptors and > >> some optimizations for such. There are some comments > >> in there outlining similar optimizations that could be made > >> for "tape-like" or "socket-like" devices. > > > > great you posted that file as reference. i believe most of the stuff done there > > should actually be done within lseek(). > > Libarchive runs on a lot of systems other than FreeBSD. > FreeBSD is not the only Unix-like system with this issue, > so that code isn't going to go out of libarchive regardless. > > If you think those same ideas can be used in dd or hd > to speed them up, please send your patches. i'm on it. ;) i'll send in the patches in a few days. > > The key point: You cannot unconditionally call lseek() > to skip over data. Instead, treat lseek() as an optimization > that can be used under some circumstances. The > question then becomes one of figuring out when > that optimization can be enabled. ...however more importantly imo is that we fix the lseek(2) man page. i'm adding a CAVEATS section, which includes some wording from the POSIX definition, regarding the fact that lseek()'s behavior on devices that don't support seeking is undefined or better: one cannot expect lseek() to return an error, if the underlying device doesn't support seeking. cheers. alex > > Tim