From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 18 12:26:06 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 720D61065675 for ; Fri, 18 Nov 2011 12:26:06 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm13-vm0.bullet.mail.sp2.yahoo.com (nm13-vm0.bullet.mail.sp2.yahoo.com [98.139.91.244]) by mx1.freebsd.org (Postfix) with SMTP id 527148FC08 for ; Fri, 18 Nov 2011 12:26:06 +0000 (UTC) Received: from [98.139.91.67] by nm13.bullet.mail.sp2.yahoo.com with NNFMP; 18 Nov 2011 12:13:18 -0000 Received: from [208.71.42.206] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 18 Nov 2011 12:13:18 -0000 Received: from [127.0.0.1] by smtp217.mail.gq1.yahoo.com with NNFMP; 18 Nov 2011 12:13:18 -0000 X-Yahoo-Newman-Id: 759634.23237.bm@smtp217.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: L_0B7kAVM1keuTtlHSFm1ZwF8cfnqp42lrNHMpPq2uG2s6E fb7dT7cRWyQ1vehP3y5lLLqRQFu1BTKJa3VfhFBsc8Y4aZa0XWj8XLXmixCP 1VeYP39EiRdsi7IRm7.bPZLY07OQLJv9HQ9mW5yvhoGjj6IGo8v1tv2BYShR P.x5Sl9xFfbECmrvqpJPopkEWToHAiA.wLSmZuaHeyriLlJXdvgW8R4qN8GJ xNQJiqYRiEdRBae1RsOJZRRsDTBQ.Uy5Q9E4upazMV9mtKg1f.4t0q2p0sCL hGkDpz0WmodJP0f.UrYO_isaF3fp0kfdpqFNvYaYsgPRKzCbqj1JEO1JX10d k2jqA3A.BPtms7yJOim84MS2.dGXFNj6u5KJdzBF_VtFZvTRneRRMAd8kxzE 2EDDGL3GmfxMWcCfk X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.150.113 with plain) by smtp217.mail.gq1.yahoo.com with SMTP; 18 Nov 2011 04:13:18 -0800 PST Message-ID: <4EC64BDE.70801@freebsd.org> Date: Fri, 18 Nov 2011 13:13:18 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <20111117175514.274040@gmx.com> <4ec5e676.P+DwfO0SrmiegcuB%perryh@pluto.rain.com> In-Reply-To: <4ec5e676.P+DwfO0SrmiegcuB%perryh@pluto.rain.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, dieterbsd@engineer.com Subject: Re: easy way to determine if a stream or fd is seekable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 12:26:06 -0000 Am 18.11.2011 06:00, schrieb perryh@pluto.rain.com: > "Dieter BSD" wrote: >> IIRC some tape drives can seek, while others cannot. >> Vague memories that it is supposed to be possible to put a >> filesystem on a DECtape and mount the filesystem. > > Back in the Bell Labs 6th Edition days, it was possible to put > a filesystem on a _9-track magtape_ and mount it, although such > a mount had to be read-only since writing to a 9-track would > effectively delete any blocks following the one written. > I've done it. Access was painfully slow (no surprise), but > it did work. > > DECtape _could_ be updated in place. It was effectively the > linear equivalent of a floppy disk (before floppy disks existed). > Sequential access was slow. Random access was very slow. I dealt with quite a number of tape formats, long agao in a former millennium, and still remember a few details ... There used to be two types of tape: 9-track (and IIRC IBM3480/90) would write variable size blocks separated by gaps, while most other formats (QIC, DLT, Exabyte, DDS) used fix size sectors (some of them emulated variable block sizes by using a variable number of sectors per logical block with an interface similar to 9-track tape drives). These drives used block headers to hold information about (emulated) block sizes and to indicate file marks or EOT marks. Linear read speed was in the range of 60KB/s (QIC-150) to 800KB/s to 1MB/s (9-track, Exabyte 8500c with compressible data), 3MB/s (IBM3480), and 6MB (DLT8000). Very expensive high speed drives went to 60MB/s and possibly beyond, but only when streaming large files. While seeks are easy to implement for formats based on sectors (and e.g. Exabyte offered "fast" seeks to sectors), each tape block may contain any number of bytes on variable block size formats. This makes direct seeks to byte offsets impossible, while it is still possible to skip any number of block or file marks. Seek times depended on the data layout on tape: linear (9-track, 3490), serpentine (QIC, DLT), or helical scan (Exabtye, DDS). Linear and helical scan tapes can skip to file marks at high speed by retracting the R/W head or lifting the tape from the head (reduction of friction and wear), while serpentine tapes just move the head to a height near the target position (DLT drives have an index of file marks in a tape lead-in block just for this purpose, which makes seeks to file marks especially fast). Due to the different hardware characteristics of tape formats, the possible semantics of seek are different. And then there is the question of how to deal with file marks (i.e. whether seeks end at a file mark, as if the end of media had been encountered, or whether the seek proceeds after the file mark, possibly to end of tape). Some tape drives supported reading/seeking to a specific block and switching to write mode without any gap. There was different behavior with regard to file and EOT marks, e.g. whether a skip to filemark stopped before or after a file mark. All these differences made it hard to deal with seek/skip semantics in the kernel, and only a few operating systems had proprietary code to fully control the vendors drives (IBM, DEC). All others just made the low level functionality available to applications, e.g. via ioctl(), and let the application (e.g. backup software) implement support for all the different tape drive behaviors (especially important for fast restore of specific data from tape). I have no idea, whether tape drives are still in wide use. For the purposes that I administrated and used tapes for (gamma/particle coincidence spectroscopy and large numerical simulations), large disk arrays have completely replaced tape storage. Disk drives are cheaper than tape cartridges, today ... Regards, STefan