On Mon, Nov 24, 2014 at 07:44:05PM +0100, Pino Toscano wrote: > I'm missing what virt-bmap would do internally, but why the need for > separate prepare + execute actions, instead of bmap_file/device doing > the actual work? This could also avoid having them stateful.
The problem that I'm trying to solve is that we need to drop_caches at some point to force the file to be really read (so it can be mapped). Now you can certainly combine the prepare+execute so a single bmap operation would do something like: bmap: drop_caches open file read file but the problem is that the 'open' is probably going to read all the directories from /sysroot down to the file, plus other metadata. This "pollutes" the data we're trying to read. To solve this I moved the drop_caches after the open: open file drop_caches read file so that the read only reads the file, not the metadata (well, mostly that's true, it depends a lot on the fs implementation). The problem now is we need to tell the caller to start reading after the drop_caches and ignore the open, so we have to split the call into prepare and execute phases. bmap_file/device: open file bmap: drop_caches read file The whole thing is probably best described as a hack anyway. I can't really see a nicer way to do it though, and this does work (at least for ext4 + ntfs which is what I've tested so far). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
