Date: Thu, 10 Nov 2011 08:09:21 -0800 From: perryh@pluto.rain.com To: imp@bsdimp.com Cc: bruce@cran.org.uk, ed@80386.nl, jilles@stack.nl, tim@kientzle.com, alfred@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call Message-ID: <4ebbf731.37OBtp%2BPJFFB1Hsl%perryh@pluto.rain.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
Warner Losh <imp@bsdimp.com> wrote: > 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. > > 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. AFAIK you can't seek(2) backward unless using something along the lines of a DECtape (remember those?), but there's no reason in principle why a forward seek(2) could not be implemented in the driver -- even without any help from the hardware. It would save some DMA, interrupt, and context-switch traffic, but even when searching for a filemark the drive won't move the tape any faster than when reading.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ebbf731.37OBtp%2BPJFFB1Hsl%perryh>