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/ | -----------------------------------------------------------------------------
