On Sat, Sep 02, 2006 at 03:21:33PM -0500, Phil Howard wrote:
> 
> | That functionality (if it will be created) should IMHO be optional, 
> 
> Absolutely.  If you want to use it, specify in the configuration.  If you
> don't want to use it, don't specify it.
> 
> 
> | considering people who aren't using removable disks but for example just 
> | one partition on their RAID. If I were one of such people, I wouldn't 
> | feel too comfortable about Amanda re-writing my server's partition table 
> | every day. It also seems to me that such functionality would need to be 
> | programmed separately for each OS - quite a bit of work.
> 
> Such partition table rewriting should only be done to a disk that is used
> exclusively for raw disk backups and for nothing else.  It should never be
> done on a disk used for other things (see alternative below).
> 
> It would not need to be separate for each OS.  The idea of using a partition
> table isn't even the only approach.  A simple header that indicates how many
> bytes or blocks the next segment of data has is sufficient.  In a way that
> is like a partition table.  But it doesn't need to be OS compatible unless
> the OS goes nuts if it can't see a partition table it recognizes (which is
> an issue you'd see with a new empty disk).  As long as the OS can always
> give you whole disk access, it's good to go.
> 
> An alternative is just to do it within a raw partition.  Use whatever scheme
> of partitioning the OS supports (manually partition it), then access each
> partition as an emulated whole tape.  Headers in front of each segment of
> data would separate the emulation of tape files.  This alternative could be
> chosen simply by specifying the partition device name rather than the whole
> disk device name.  The driver implementation would simply work with what is
> given to it, be that a whole disk or a partition of a disk.

Phil,
what advantage(s) do you forsee in amanda's use of raw disk
devices as opposed to files on the native filesystem.

It certainly would destroy one of amanda's features,
the ability to easily recover backup data using
standard unix utilities without amanda software.

I've not heard people on the list reporting poor performance
in using the current scheme for saving backups on disk-based
'virtual tapes'.  If there are, I'd like to know about it.
Given that the backups are coming from dump or tar, possibly
over a network, possibly processed by compression and encryption
software, it is unlikely that the final disk writing is a bottleneck.

Perhaps additional features would be possible.  Like multiplexed
"direct to tape" dumps without a holding disk.  The current scheme
only allows a single dump direct to tape.  Multiplexed dumps have
to go to a holding disk before being taped.

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)