User:Nikolas/New Taper Design Notes

Old

Flow of data

1. Dumper
2. Chunker
3. Holding disk (not a process)
4. Taper

Or (no holding disk):

1. Dumper
2. (via port) Taper

New

Flow of data

1. Dumper
2. Holding disk
3. Taper
   • Taper::Feeder (reads from holding, tells scribe where to find data if it needs to backtrack)
   • Taper::Scribe (writes to devices)

Or (no holding disk):

1. Dumper
2. Taper
   • Taper::Feeder (reads from port)
   • Taper::Scribe (writes to devices)

Notes

• Chunker doesn't change at all
• The details of reading from holding disk are handled by a Xfer object
• Taper::Scribe handles splitting dumpfiles for tapes??

Taperscan

Taper scans are deferred to an object, so we can implement several taperscan algorithms with different classes, and just swap them in based on a config parameter.

Buffering

The hardest part about this is that Taper::Scribe may need to backtrack in the datastream if it encounters EOM in the middle of a split part. It (well, the underlying Amanda::Xfer::Dest::Taper) buffers data in memory or on disk, *unless* it is told by e.g., Taper::Feeder that the data is already available somewhere on disk.

New XFA Parts

• Xfer::Source::HoldingDisk($filename) - used by Taper::Feeder
• Xfer::Dest::Taper($buffer_size)- used by Taper::Scribe; has lots of "I need a new tape" and "I'm starting a new file" callbacks