Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The mt(1) manpage describes seeking on files, records, and file marks, but doesn't explain what any of them are. What's the difference between these these options? (It sounds like file marks are stored on the tape on a special track or something, but I can't seem to find any discussion of the others.)


So, all from a few years old memory and its a complex interwoven mess.

Lets start with tape has two types of head positioning commands, locate and space. Locate is absolute (and mt calls it seek), and space is relative. Mt is generally using space (although one can read the current position with tell then do relative space) for all the commands that aren't "seek". Hence the mt commands are things like "fsf" which is forward space file (mark), or "bsf" for back space file (mark). At some point in the past someone thought that each "file" would fit in a tape block, but then reality hit because there are limits on how large the blocks can actually be (in linux its generally the number of scatter gather entries that can fit in a page reliably). So there are filemarks, which are like "special" tape blocks without any data in them. Instead if you attempt to read over a filemark the drive returns a soft error telling you that you just tried to read a filemark. There are also "fsr" for forward space records with are just the individual blocks forming a "file".

So back to seeking. If you man st, you will notice that each tape drive gets a bunch of /dev/st* aliases, which control the close behavior/etc, as well as some ioctls that match the mt commands. The two important close behaviors to remember are that if the tape is at EOD due to the last command being a write it will write a filemark, then rewind the tape unless a /dev/stXn device is being used, in which case it will leave the head position just past the FM (this is actually a bit more complex too because IIRC there may be two filemarks at EOD, and the tape position gets left between them).

This allows one to do something like "for (x in *.txt); do cat $x >> /dev/st0n; done" and write a bunch of files separated by filemarks (at the default blocking size which will be slow (probably 10k), replace the cat with tar to control blocking/etc). Or if you want to read the previous file `mt -f /dev/st0n bsf 2` to back space 2 filemarks.

Now, the actual data format on tape is going to be dictated by the backup utility used to write it. Some never use filemarks, some do but as a volume separator (eg tar), old ones actually put FM's between files, but that tends to be slow because it kills read perf because it takes the drive out of streaming mode whenever you either read over the filemark (not the part on man st about reading a filemark).

Now you can pick which file to read via "mt -f /dev/st0 rewind; mt -f /dev/st0n fsf X; cat /dev/st0n > restore.file"

There are also tape partition control commands, and tape set marks and various other options which may/may not apply to a given type of tape. Noticeably there are also density flags on the special file (some unix'es) and via mt. LTO for example doesn't have settable densities because its fixed by the physical tape in the drive. Some drives STK T10K/IBM TS11X0/3592 can upgrade the tape density/capacity when used in a newer drive.

That got long...


Thanks, that was an interesting explanation. Though it does lead me to ask: what is a "set mark" and how does it differ from a "file mark"?

`man st` does a much better job of explaining the difference between `fsf` and `fsfm` than the `mt` docs:

       MTFSF         Forward space over mt_count filemarks.

       MTFSFM        Forward space over mt_count filemarks.  Reposition the tape to the BOT side of the last filemark.
I’ve got a project that would work very well with linear data streaming, but it looks like even the cheapest of used tape drives probably only break even with HDDs in the tens of terabytes. Ah well, one can dream...




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: