Date: Fri, 19 Feb 2010 09:34:27 +0100 From: "Matthias Andree" <matthias.andree@gmx.de> To: "Tim Kientzle" <kientzle@freebsd.org>, freebsd-hackers@freebsd.org Subject: seeking and seekability (was: "tar tfv /dev/cd0" speedup patch) Message-ID: <op.u8c8rpf21e62zd@merlin.emma.line.org> In-Reply-To: <4B7E1BA5.7050209@freebsd.org> References: <20100217215940.GA19713@triton8.kn-bremen.de> <4B7CE066.4030403@freebsd.org> <20100218183459.GA65508@triton8.kn-bremen.de> <20100218191347.GA4040@britannica.bec.de> <4B7E1BA5.7050209@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 19.02.2010, 06:03 Uhr, schrieb Tim Kientzle <kientzle@freebsd.org>: > Joerg Sonnenberger wrote: >> On Thu, Feb 18, 2010 at 07:34:59PM +0100, Juergen Lock wrote: >>> Ok here is a new version of the patch with these things fixed and the >>> Linux case added: (Linux case not tested yet, and yes I did this on >>> stable/8.) >> Why the check at all? Shouldn't devices that don't allow seek fail >> that? >> E.g. for devices, just try to seek ahead and fallback to normal reading? > > That was the initial implementation in libarchive, but > I had a number of reports of that not working for > tape drives. I recently dug out and connected an > old DDS drive I had in the closet, so I should > probably try again and see if I misunderstood > something along the way. I'd already written this in a private email to Tim before I came across this continued discussion on -hackers@, I'll paste a modified version of my own part: I strongly believe that someone should really fix lseek() in FreeBSD outside GEOM. There is precedence, namely <http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/60313>; and it was never properly fixed. The PR was closed because the actual reported problem on da(4) no longer occurred since FreeBSD 5 after the GEOM migration, and my issue was with da(4) on FreeBSD 4. Now I'm learning that the very same bug persists through -CURRENT nearly a decade later: after lseek devices such as sa(4) will return "garbage" (i. e. from the unchanged offset) rather than failing. It should be sorted out before 8.1. Am I naive if I expect lseek to return (off_t)-1 with errno == ESPIPE on non-seekable devices? I'll concede that sa(4) is neither socket nor pipe nor fifo in the strict sense, but all share the non-seekability. If lseek() can't know the device isn't seekable, subsequent I/O operations should return EIO along with a proper kernel log message for the first occasion per process, but that would not help applications or libarchive for that matter - they will need a canonical way to find out if a device is seekable. Unfortunately FreeBSD maps many physical block devices that are unbuffered to character special device nodes, so the obvious way of calling [f]stat() and then checking S_ISBLK(st.st_mode) will return FALSE even for devices that can seek. -- Matthias Andree
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.u8c8rpf21e62zd>