Date: Fri, 11 Nov 2011 16:08:31 -0800 From: Tim Kientzle <tim@kientzle.com> To: Warner Losh <imp@bsdimp.com> Cc: arch@freebsd.org, "arch@" <freebsd-arch@freebsd.org> Subject: Re: [PATCH] fadvise(2) system call Message-ID: <4698F60B-CBF7-4D80-9368-CC6FBD893C0B@kientzle.com> In-Reply-To: <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <CAGE5yCoTvYNXNc37V0%2Bt783uh=6J-_J-dt_Km_4xbO7O2O2BUw@mail.gmail.com> <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 9, 2011, at 10:46 PM, Warner Losh wrote: >=20 > On Nov 9, 2011, at 11:03 PM, Tim Kientzle wrote: >> Anyone know how to properly request a "skip forward" >> on tape drives? That's one of the missing pieces. >=20 > I thought that you couldn't seek(2) on tape drives. You must read(2) = the data. At least for this application, since a tar file would be just = one file on the tape. If you want to see to the next file mark, you = need to use an ioctl to get there, or read a lot. Yes, seek(2) is badly broken on tape drives. It does nothing and = doesn't return an error (unlike seek(2) on pipes, which does return an = error). I've seen references to ioctls that are supported by some drivers and/or = hardware that allow skipping forward by some number of records. But I = don't know the details. I doubt it's a major performance optimization in most cases, but it = would still be nice to avoid copying the data all the way down just to = ignore it. Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4698F60B-CBF7-4D80-9368-CC6FBD893C0B>