|
|
 |
 |
 |
 |
 |
 |
|
|
|
From: Jay Miller (jnmiller, cryptofreak dot org) Date: 2001.09.26 - 14.46 MDT
X-Mailer: Mutt 1.2.5i Hi. I thought I would brief you all on the results of the short meeting Don and I had this morning, and fill you in on some other minor stuff I did. We worked through a couple other use cases. Here's some text about them, though Don has them more officially documented. * Virus checking We only considered virus checking at the time of backup, rather than file creation/write time. For performance reasons, this is all that makes sense, and I don't *think* anyone had expected otherwise. (?) Checking for viruses therefore because a step in the backup use case we all did yesterday. However, we thought it made sense to postponed virus checking in particular and just consider a generic 'Backup Preparation' interface. It would be a way for miscellaneous modules to plug in to our ADCs and preform whatever sort of action is needed. Examples might include compression, encryption and, of course, virus checking. In any of these cases, the module is extremely small: just a command line interface to analyze the snapped file in the appropriate way. Neat, we thought. * Auto-restore This idea may not be so popular, but after thinking about it for a bit, Don and I thought it might actually be kinda slick as well as being the only right way to do it. Auto-restores begin with an open() request for a migrated file. That open will block while the ADML manages to restore the data. On disk at that time, we believed, is a 0-length file representing the real file. Fine. All good. The ADML sends a request out for the specified file, and that file is read from tape (or whatever). We can't just restore the file directly to the file system from the top, however, because we won't be able to differentiate that open from any other open (or a write, or whatever). We therefore thought that our software will be required to send the raw data straight to the ADML level and have it make the write() calls to the file system. When the data is restored in this manner, the PD is updated and the original open() is unblocked. Kinda neat, though it might sound hairy at first. * Archive/migrate a file This one turned out a bit complicated. No description from me! ... In other news, this email was sent, as you can see, to 'antera, cryptofreak dot org'. This is a mailing list so I don't have to manage all those damn email addresses in the To: line. Another benefit of such a thing is privacy: anyone seeing this email will see only what you can see, namely sender and the list name. While it's not really a big deal, it could provide a little protection sometime. (And no, you can't expand the list at my SMTP server.) One other benefit is the ability to have a central archive (ha!) of all of this crap we're sending. Which leads me to.. I also setup a little website that might be a nice place to deposit code and documents. The list archive is also found here. http://www.cryptofreak.org/projects/antera/ It's all protected by the following access info: user: antera pass: asc-GUEST Check it out, if you like. There's also instructions on using the list and, if you like, adding names to the list. For now, if you want to email the list, just send to antera, cryptofreak dot org. -- Jay Miller ICQ: 32123421 | YM: ladenedge | http://www.cryptofreak.org PGP: 0xedc9bb8d | 41a6428c 46abd36b 6b259b68 8a28ca4c edc9bb8c -- This is the antera mailing list. To unsubscribe, email majordomo, cryptofreak dot org with message body `unsubscribe antera'. Or, for more information, visit http://www.cryptofreak.org/.
This archive was generated by hypermail 2b30 : 2001.09.27 - 03.00 MDT |
