On Sat, Sep 02, 2006 at 11:23:32AM +0300, Toomas Aas 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.

The reason I thought of using the DOS partition scheme was in implementing
it as a Linux kernel driver.  In Amanda, any way to divide up the disk as
is given to it in the configuration could be chosen by the programmer.

FYI, I was benchmarking some disk writing for an unrelated purpose yesterday
and found that in Linux 2.6 using the O_DIRECT option when opening a device
to write on a disk raw (even a partition) results in much faster writing.
Writing raw already beats writing through a filesystem.  Raw with O_DIRECT
is much faster than raw without.  If someone does decide to write a driver
for raw disk support, I suggest having its implementation test for support
for the O_DIRECT option, and use it where possible.  It does have some size,
offset, and alignment requirements that vary by OS.

-- 
-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------