Pseudo block driver
|In order to start this driver, you must be logged in as root.|
devb-loopback [loopback loopback_option[,option]] [blk option[,option]...] &
|Use commas (,) to separate the options. You can put the blk and loopback groups of options in any order.|
Each pathname will result in the creation of a corresponding block-special device (see prefix= below), the content of which will be mirrored over the file descriptor using standard read/write calls. You can then mount traditional block filesystems (such as fs-dos.so and fs-qnx4.so) on top of these pseudo devices and use them transparently.
You can specify multiple fd= pathnames; they're managed by a single devb-loopback process.
|This option affects writes that are presented to the pseudo-device, and not the write behavior of any mounted filesystems above this (that can be controlled via mount options or blk delwri=... commit=...).|
The default is sync.
You might also need this option in some cases where a filesystem image was originally formatted on a device with a different sector size to that of the hosting filesystem; it may be necessary for correct operation or performance reasons to mimic the original sector size.
This option applies to all subsequent instances of fd=, but you can reset it to use the probed value with an empty option (e.g. blksz=2048,fd=/F1,blksz=,fd=/F2).
The default is 1; you can specify a value of 0 to force all I/O to be performed synchronously in the context of the filesystem caller; it can be higher to prevent this I/O from becoming a bottleneck to the filesystem layers above (appropriate only when multiple fd= paths have been specified). This is a global option; the pool of threads services requests to all fd= files in the order of client priority.
The blk options are as for io-blk.so. If specified, they must follow the blk keyword. For more information, see io-blk.so.
Since devb-loopback loads the standard block device DLLs, which will create a buffer cache using the same default rules as for the disk filesystems, the cache is likely to be too big for devb-loopback. You can reduce the cache size using blk cache=size. Depending on the actual size of the device, and the level of caching already implemented by its driver, a value of 128k may be sufficient.
The block filesystems in QNX Neutrino are implemented as a series of DLL modules and a set of internal APIs. Thus it is possible to mount disk-based filesystems (such as QNX or DOS) only onto released QNX devb-* drivers. The devb-loopback driver implements a mapping between an arbitrary file descriptor and the block API, allowing any resource manager to be used to host a disk filesystem.
Internal function calls, normally targeted at a SCSI/CAM driver, are translated into standard read() and write() calls onto the host file descriptor, and are used to populate the data content of a pseudo block device, which appears to the system as a disk.
Within this framework, any resource-manager or file-descriptor object can be viewed as a block-special device and be mounted as a disk filesystem. For example, you can't normally directly use an ISO9660 image stored on a devf-* device, because devf-* doesn't load fs-*.so modules; by using devb-loopback to present this image file as a block device, you can then mount it using fs-cd.so. For example:
devb-loopback fd=/devf/iso blk automount=lo0:/fs/iso:cd
This results in the following arrangement:
Other uses might be to mount images from /dev/shmem, an image filesystem (IFS), or over NFS.
The host file needs to be pregrown. For example, assuming that /fs/flash is a mounted devf filesystem, you'd have to do the following setup first:
touch /fs/flash/q4.img dinit -hq -S32m /fs/flash/q4.img
You could then use that file on flash as a read-write fs-qnx4.so filesystem:
devb-loopback blk cache=128k,auto=none loopback fd=/fs/flash/q4.img mount -tqnx4 /dev/lo0 /q4flash
Using devb-loopback in this case adds functionality that a disk filesystem format offers (access times, hard links, etc.) to the devf-* filesystem. In other cases, devb-loopback lets you use the caching (e.g. names and sectors) that io-blk.so supports, but that the resource manager underlying the host file might not.
The resource manager(s) implementing the pathnames specified by fd= operands must support the following standard interfaces:
You can mount the filesystem image via the loopback device (/dev/lo*) from the command line with the mount command:
# devb-loopback blk cache=256k,vnode=128 \ loopback ro,blksz=2048,fd=/mnt/EFS/tts.iso & # mount -r -tcd /dev/lo0 /mnt/tts
or via the blk automount= option:
# devb-loopback blk cache=256k,vnode=128,automount=lo0:/mnt/tts:cd \ loopback ro,blksz=2048,fd=/mnt/EFS/tts.iso &
You can use umount to unmount the filesystem. The file descriptors to the underlying host image files aren't closed, and /dev/lo* remain present, until devb-loopback is terminated.
cam-*, devb-*, fs-*, io-blk.so, mount, umount
close(), devctl() fstat(). open(), pread() pwrite() read(), stat() write() in the QNX Neutrino Library Reference
Writing a Resource Manager