[libvirt] [PATCH] storage: Support different wiping algorithms

[Daniel P. Berrange]

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