No, an AT&T unix 'close' will position after the filemark... The bsd unix close positions before the filemark.
Hence if you use the wrong device (mainly a Solaris thing) the backup s/w gets confused due to multiple filemarks between data. e.g. /dev/rmt/0cn (at&t close) Vs /dev/rmt/0cbn (bsd close) With Linux, you need to perform some sort of ioctl() to change the device close behavior Thankfully, Linux defaults to bsd behaviour. Cheers Mark -----Original Message----- From: Richard Sharpe [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2008 10:17 AM To: Mark Harvey Subject: Re: [Stgt-devel] Dealing with filemarks in SSC ... On Tue, Jul 29, 2008 at 4:54 PM, Mark Harvey <[EMAIL PROTECTED]> wrote: > Both NetBackup and NetWorker use the following filemark handling. > > [data][filemark1][data][filemark1][data][filemark1][filemark2] > > Using the 'bsd' close (vs AT&T close), the tape head is positioned after > [filemark1] and before [filemark2]. A new 'write' command will overwrite > [filemark2]. So, reading between the lines, if you have been writing, a BSD close writes two filemarks and then positions the tape between them ... > Using this method, end of valid backup data is easily detected by two > consecutive filemarks on tape. If there is only one filemark, there is > more valid data to follow. > > Note: filemark1 and filemark2 are just 'filemarks' - they are not > different types of filemarks. (Just in case this created any sort of > confusion). > > Cheers > Mark > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sharpe > Sent: Wednesday, July 30, 2008 9:45 AM > To: stgt-devel > Subject: [Stgt-devel] Dealing with filemarks in SSC ... > > I have been looking at this issue of filemarks in SSC, and it seems to > me that there are a couple of questions that need to be answered. > > For example, if there are two file marks on a tape, or even three, and > you write records onto the tape and overwrite one of the file marks, > in some sense the drive should still be able to seek to the old second > filemark (now the first filemark) ... and reliably recover the third > file on the tape. > > I don't know if any software depends on that behavior, though. > _______________________________________________ > Stgt-devel mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/stgt-devel > _______________________________________________ Stgt-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/stgt-devel
