On Mon, Jan 09, 2012 at 11:05:28AM +0100, Michal Privoznik wrote: > On 03.01.2012 17:39, Daniel P. Berrange wrote: > > On Tue, Jan 03, 2012 at 05:12:47PM +0100, Michal Privoznik wrote: > >> Currently, we support only filling a volume with zeroes on wiping. > >> However, it is not enough as data might still be readable by > >> experienced and equipped attacker. Many technical papers have been > >> written, therefore we should support other wiping algorithms. > >> --- > >> Okay, this is not as complete as I'd like it. Wiping could take ages, > >> therefore we *want* it to be asynchronous. But that would mean: > >> > >> 1) Create new API to answer: "Are we done yet?" > > > > IMHO, we basically want to duplicate the async job system from > > virDomainPtr, for virStorageVolPtr. > > > > eg, > > virStorageVolAbortJob(virStorageVolPtr vol); > > virStorageVolGetJobInfo(virStorageVolPtr vol, > > virStorageVolJobInfoPtr info); > > > > this would be useful for several other storage vol related > > APIs. We might also want similar APIs against virStoragePoolPtr > > > >> 2) Create event emitting system - like we have for domains > >> > >> 3) Combination of previous two > >> > >> In fact, I've started writing events, but it turned out to be > >> huge and I am not even in a half yet. I need to find a way of > >> re-using event code we already have. But thats another day and > >> another patch set. > > > > Yes, the abilty to support async events for other objects like > > virStoragePoolPtr, virStorageVolPtr, virNetworkPtr, etc is a > > well overdue todo item. > > > > > > I think it would be acceptable todo option 1 as the first > > impl, and then add option 2 as a follow on patchset, since > > events are merely an optimization. > > > > Daniel > > One thing I am wondering about is - can we separate these steps? I mean, > take this part in and do the rest in follow up patches. Certainly, > writing JobInfo for storage is rather huge code to be written and thus > worth its own patch set. Moreover, this functionality can be desired by > many products based on libvirt that want to be certified (e.g. PCI DSS) > and thus need other wiping algorithms than just zeroing. From this POV > is JobInfo just a "nice to have" feature. Sure, the storage wiping code is already slow, so there's no reason to reject your current patch on the basis of speed. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list