Date: Sun, 20 Nov 2011 12:40:34 +0000 From: Alexander Best <arundel@freebsd.org> To: Tim Kientzle <tim@kientzle.com> Cc: freebsd-hackers@freebsd.org, Juergen Lock <nox@jelal.kn-bremen.de> Subject: Re: easy way to determine if a stream or fd is seekable Message-ID: <20111120124034.GA54811@freebsd.org> In-Reply-To: <E693FAEB-1D8D-41A0-AEB7-3EB00419F432@kientzle.com> 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> <B06B2304-A1BC-49A3-A811-F05625138D58@kientzle.com> <20111118203122.GA9508@freebsd.org> <E693FAEB-1D8D-41A0-AEB7-3EB00419F432@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111120124034.GA54811>