On 5/22/19 4:55 AM, Richard W.M. Jones wrote: > So last night I had an important thought about this: > > * What existing export names are people using in real life? > > nbdkit doesn't use export names for anything - you can pass > anything you like. > > qemu-nbd has an odd system where the export name must match what was > specified on the command line, but AFAIK it doesn't care about it > otherwise. In the future, qemu-nbd may be taught to support multiple exports on a single server. At which point export names matching will matter more. > > qemu's internal NBD server may permit multiple export names, but I'm > not totally sure about that. What do they look like? Arbitrary > strings? Absolute paths? Relative paths? Whatever the caller wanted. In my work to add incremental backups to libvirt, I create a single NBD server, then add one export per disk with names chosen by libvirt, giving output such as: # qemu-nbd --list -k /var/lib/libvirt/qemu/pull.sock exports available: 2 export: 'vda' size: 6442450944 flags: 0x4ef ( readonly flush fua trim zeroes df cache ) min block: 512 opt block: 4096 max block: 33554432 available meta contexts: 1 base:allocation export: 'vdb' size: 104857600 flags: 0x4ef ( readonly flush fua trim zeroes df cache ) min block: 512 opt block: 4096 max block: 33554432 available meta contexts: 1 base:allocation But the point is they are arbitrary strings, not paths. > > nbd-server supports multiple export names, and it does appear to want > absolute paths. Can it use arbitrary strings too, or are absolute > paths the only option? How about relative paths? > > Basically, I think what we most commonly use export names for should > influence how we decide to use them in URLs. Right now, the NBD spec is silent on whether / is used in typical pathname resolution style, or must be treated literally. And there are enough uses out there that it may be hard to add semantics now other than preserving things as a literal string (/ does not change directories, // cannot be simplified to /, etc). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature