"John R. Jackson" <[EMAIL PROTECTED]> writes:
> >Why doesn't Amanda use the following portable, non-destructive write test:
> >
> >read label; amlabel -f config label
>
> How do you figure this is non-destructive? It completely clobbers all
> access to data beyond the label. What if there was some problem and
> amcheck was happy with the tape but you realized some other way it was
> not what you wanted to use for the next backups?
>
> I'd just as soon defer writing on a tape until the last moment.
>
> What's really needed is a non-destructive "can I write on this
> tape" method, e.g. a test of permissions or access(). But that's
> (unfortunately) highly OS dependent, if possible at all. Grrrr.
>
> >Johannes Niess
>
> John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
John,
AFAIK the label has a fixed size of 64kB, so writing it over itself
should not change a single byte. Even an interrupted write should
leave the data in good condition, as long as it does not change a
byte. If this happens, the whole tape is doomed anyway. And we should
have more tapes than dump days as a backup for the current tape for
similar reasons.
Hardware issues like tape stretching could cause the
trouble. Introducing new standard API's on a lot of operating systems just
for amanda's sake won't happen, so we could resort to this workaround.
I agree that the write test should stay non-default to amcheck. It's
always a compromise between keeping old backups intact and ensuring
new backups can get written.
Tape stretching was the issue with "append to tape", too. As disks get
cheaper and this feature will be used mainly for small backup sizes,
why not restore the old tape to holding disk, add the new data and
write everything to tape again? It's more like a "append to disk"
feature. It's painfully slow, but might be acceptable in small
installations because dump time for new data does not change. Old data
is save, in case of errors it stays in the holding disk.
Just some (new) thoughts for the developers, that should not distract
you and the others from coding the features you want.
Johannes Niess
