From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 00:08:43 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A584C106564A; Sat, 12 Nov 2011 00:08:43 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 7F7B38FC13; Sat, 12 Nov 2011 00:08:43 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id pAC08VYX011327; Sat, 12 Nov 2011 00:08:31 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id n74ug67nywvwh28zvsvpmvy6da; Sat, 12 Nov 2011 00:08:31 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> Date: Fri, 11 Nov 2011 16:08:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4698F60B-CBF7-4D80-9368-CC6FBD893C0B@kientzle.com> References: <201110281426.00013.jhb@freebsd.org> <4EB2C9DD.9090606@FreeBSD.org> <20111104160319.GD6110@elvis.mu.org> <201111080800.32717.jhb@freebsd.org> <6E287E90-AA62-4776-A09D-394D69C9494F@kientzle.com> <1B4CA8AC-8798-40CD-9379-FA0F379558DE@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1251.1) Cc: arch@freebsd.org, "arch@" Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 00:08:43 -0000 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