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/