Amanda-3.1.0 isn't *quite* out the door yet, but like all developers
at the end of a release cycle, we have turned our thoughts to the next
feature release, Amanda-3.2.0. This wistfulness happened to coincide
with a trip to Sunnyvale for all of us telecommuters at Zmanda, making
it a perfect time to put our heads together and decide what to do next
-- and more importantly, what to leave undone for the moment.
We're looking to make the 3.2.0 release soon - perhaps as soon as four
months (August). So we've selected a number of well-contained
projects that are manageable in that timeframe. This plan is, of
course, subject to revision, particularly if we see additional
developers come onboard.
1. Smoother configuration and handling of filtering (compression and
encryption), making it easier to set up customized filters, and to use
different filters for different DLEs.
2. Logical EOM handling, allowing most devices to write data all the
way to the end of a volume without losing any data. This allows
Amanda to use volumes completely, and avoids the need to use those
pesky split buffers.
3. Vaulting support for splitting and reassembly (for real this time, I swear)
4. Recovery and taper scan improvements, including more configurable
searches for tapes, ability to "chain" multiple changers for
recoveries, improvements in interactivity ("feed me volume ___"), and
just generally a lot more flexibility and predictability in Amanda's
behavior toward volumes.
5. Support for simultaneous writes to multiple tape drives. The
technical support for this is in place, so the configuration and
management is the hard part: how does Amanda decide which tape to put
a DLE on? Can the DLE "jump" from tape to tape? How does Amanda know
how many drives it can use? What does it do if one of them is in use?
Yeah, it's complicated!
6. A DirectTCP-based media server daemon. This is basically a changer
and its associated devices (tapes, vtapes, cloud, whatever) on a
machine *other* than that running the Amanda server. Amanda uses
DirectTCP to send data directly from the client tot he media server
daemon, completely bypassing the Amanda server machine. Combine this
with point #5, above, and Amanda gets a *lot* more scalable!
Of course, we will have bugfixes to think about (those will end up in
patch releases numbered 3.1.x, x>0), and a number of loose ends to
clean up and long-term projects to push forward:
- consistent treatment of include/exclude lists across applications
- perl rewrites on the server side
- tear out some old, unused code
Likewise, if time gets tight, we may implement some of these items in
a limited fashion - in particular, I can think of some "dumbed down"
implementations of #5 and #6 that would be much easier to write while
still providing significant benefit to Amanda's users.
I'd love to see comments on this list, and I'd especially like to hear
from anyone who wants to add a project *and* work that project through
to completion!
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
