Christoph Hellwig wrote: > On Mon, Jun 21, 2010 at 09:51:23AM -0500, Anthony Liguori wrote: > > I can appreciate the desire to keep protocols and formats as an internal > > distinction but as a user visible concept, I think your two examples > > highlight why exposing protocols as formats make sense. A user doesn't > > necessarily care what's happening under the cover. I think: > > > > -blockdev format=qcow2,file=image.qcow2,id=blk1 > > > > and: > > > > -blockdev protocol=vvfat,file=/tmp/dir,id=blk1 > > > > Would cause a bit of confusion. It's not immediately clear why vvfat is > > a protocol and qcow2 isn't. It's really an implementation detail that > > we implement qcow2 on top of a "protocol" called file. > > Everything involving vvfat will end up in sheer confusion, and that's > because vvfat is such a beast. But it's a rather traditional example > of a "protocol". Unlike qcow2 / vmdk / vpc it can not be stacked on > an arbitrary protocol (file/nbd/http), but rather accessed a directory > tree.
There is no technical reason why vvfat couldn't be stacked on top of FTP or HTTP-DAV or RSYNC or SCP, or even "wget -R". Basically anything with multiple files addressed by paths, and a way to retrieve directories to find all the paths. vvfat doesn't stack on top of "file-like protocols", it stacks conceptually on top of "directory tree-like protocols", of which there is currently one. The arrival of Plan9fs may motivate the addition of more. You can't meaningfully stack "qcow2" or any other format than "raw" on top of the virtual file image created by vvfat. So that's another reason it isn't the same as other "protocols". -- Jamie
