Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!howland.erols.net!news.mathworks.com!fu-berlin.de!irz401!orion.sax.de!uriah.heep!news From: j@uriah.heep.sax.de (J Wunsch) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Tape file system Date: 23 Mar 1997 20:51:27 GMT Organization: Private BSD site, Dresden Lines: 82 Message-ID: <5h454f$ii7@uriah.heep.sax.de> References: <5h0pfc$7vg@fu-berlin.de> Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) NNTP-Posting-Host: localhost.heep.sax.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: knews 0.9.6 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:37634 gusw@zedat.fu-berlin.de (Gunther Schadow) wrote: > is it possible to write a file system onto a tape and then mount it > like a disk? Wasn't this possible on the VAX? It's only possible for block-addressable tapes. For writing, this means you need a 9-track half-inch reel-to-reel tape. For read/only, you might perhaps get away with a DAT tape already. Of course, you need the silly old unix file system for it in order to do something halfways reasonable at all. Using the disk-optimized Berkeley FFS is most likely nothing else than a good hardware test for your tape drive. :-) (Maybe it you can simulate the old behaviour by forcing everything into a single cylinder group.) The tape block device nodes (/dev/st0, major #5, minor #0) in FreeBSD are broken for some reason. You can't really read or write something with them. I once tried to debug the problem, but eventually gave up. Sure, it would be something worth to do for fun (in particular if one still has a half-inch drive, too ;-), but it's nothing you would ever use for serious work at all. > On HP-UX you can even > boot from tapes, can't you? That's a different problem. Something you probably won't ever get with a PC, simply since the BIOS manufacturers don't even believe somebody would have a use for this (what you would need in order to do this is some kind of BIOS device access in the BIOS ROM). This is totally unrelated to filesystems. It's usually done by using a tape file containing a memory filesystem image, or by using a filesystem image that is installed in the swap area as a so-called miniroot. > An other question is, why (or whether) lseek is not yet implemented > like doing fast seeks as `mt fsr ...', any problems here? Should > I just add an lseek system call for the st.c driver? No such thing like an lseek entry point to the device drivers. All that lseek(2) does is to notify the upper layers that the next request will go to a different address; this is in no way passed down to the device drivers. All the device drivers see is that the next buffer passed to the strategy entry point is on a different device address. Translating this into a tape seek operation might seem useful, although it's not very simple. It's not supported by all tape drives anyway, and for those that support it, you need to ensure that the request won't go beyond the limits of the current tape file. (How do you handle different tape files in an lseek() context anyway?) Also note that some tape drives, while offering the ability to go backwards by one record, simply have a _terrible_ performance doing this (i know it for example for the good ol' Archive Viper 150). They can only read forward, thus in order to go one record backwards, they go a larger amount backwards, and read ahead until the next tape block is under the head. Seeking back by 100 records on them is an operation taking about 2 hours... > I am asking because I feel like the tar (`Tape ARchive') is not as > well tailored as it could be, ... It ain't, but its actual value is not that it would handle tapes in an efficient manner, but in that it's a fairly universal archive format that is understood by many systems. Unfortunately, you're some 10 or 20 years too late if you wanna change the tar format today. :-) > Dump(8) has a nice directory feature `restore -i'is very comfortable, > however, restore does not seek quickly but reads over the whole tape. Restore could perhaps be taught to use the MTIO* ioctls in order to seek to the desired block, as opposed to reading all the blocks. However, take care to not break the end-of-medium handling. When you read a restore tape, you never know which is the last i-node present on the current tape, until you perused through end-of-medium... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)