Create loopback adapter using only part of file

J

johnpeeb

Does anyone know if it is possible to create a loopback adapter using only part of (say the first 1GB) of a file without copying the file? What I am specifically after is a way to create a block device which contains 1GB of zeros backed by /dev/zero.
 
"Loopback mount" is Linux terminology, which is done with mdconfig(8) on FreeBSD. You say "backed by /dev/zero", but it's not clear whether you mean a device that is always zeros, or you really do want to store data there but just have it initialized to zeros.

For the second case, it's quick to create a sparse file:
# dd if=/dev/zero of=/tmp/1gzeros bs=1 count=0 seek=1g
ISTR there's another, easier way to create that, but can't recall it.

# mdconfig -f /tmp/1gzeros
This will return a device name.

Sparse files are quick to create but may not perform very well otherwise. Depends on what you're doing.

Creating a full 1G file shouldn't take all that long if you use a large block size. Eight seconds here:
# dd if=/dev/zero of=/tmp/1gzeros bs=1m count=1k
 
Thanks for the response.

Sorry about the lack of clarity. I actually meant the first case. (The device is always zeros regardless of what is written or to it.) I tried playing around with mdconfig.

It looks like the -s option does what I'm looking for but there are two issues. First it doesn't seem to like it when you tell it to use a block device instead of an actual file to back the disk. I get

Code: 
>> mdconfig -a -t vnode -s 1g -f /dev/zero
mdconfig: ioctl(/dev/mdctl): Invalid argument

Second (and this one isn't really an issue for me right now, but it would be nice to know), devices created with a size of less than 512 bytes get created alright, but when you try to read them, you get

Code: 
>> cat /dev/md0
cat: /dev/md0: Device not configured

(The exact same device when created with a block size of at least 512 bytes works fine.)
 
johnpeeb said:
(The device is always zeros regardless of what is written or to it.)
Click to expand...
What you're describing is /dev/zero. You don't need another device. If you need to refer to it by another name, use a symlink.

johnpeeb said:
Second (and this one isn't really an issue for me right now, but it would be nice to know), devices created with a size of less than 512 bytes get created alright, but when you try to read them, you get
Click to expand...
I guess it has something to do with minimum disk block size being 512 bytes.
 
FreeBSD doesn't have traditional block devices. I do occasionally use that terminology but it's technically incorrect. Things like hard drives and /dev/zero are special character devices with unique properties. I know of no way that a special zero device can be the backing store to an md device.

I'm really struggling to imagine any use for a 1 GB file that accepts writes but always reads zero. Can you explain what your true goal is? Perhaps there is a better way to achieve it.
 
Galactic_Dominator said:
I'm really struggling to imagine any use for a 1 GB file that accepts writes but always reads zero. Can you explain what your true goal is? Perhaps there is a better way to achieve it.
Click to expand...

Reading the linked sparse file site more carefully, it looks like this may actually serve my needs. When I first read it, it looked like it was saying that a 16gb file of all zeros would still take up 1gb of space, but reading it again, it appears that it would take up almost no space.

I've been trying to boot a Windows slice that resides on the same disk as FreeBSD in a virtual machine running from within FreeBSD, and unfortunately, the virtual machine needs to think it has read/write access to the entire disk to do this, even though (as far as I am aware) it only uses the access to read/write to the specific partition.

Ideally, what I would do is copy the MBR to a file (and modify it appropriately), create a character device with md backed by the file, then use gconcat to glue it together with the windows slice. However, it is my understanding that Windows gets unhappy if the starting location of its slice changes, so I need to put ~100gb (1gb in the previous posts was just an example) of padding between the end of the MBR and beginning of the Windows slice that I could use with gconcat.

I wanted to have something backed by /dev/zero because it would take up no space (and it won't be written to so it doesn't need to save writes), but since it appears that sparse files also take up a negligible amount of space, they should work fine.

I'm open to other suggestions on how to accomplish this, though. Also, the virtual machine software I'm using is VirtualBox, but if anyone knows of software with better raw partition access support that runs on FreeBSD, I'd probably just use that instead.
 
Your premise
the virtual machine needs to think it has read/write access to the entire disk to do this
Click to expand...
is false. Just map the VM straight the partition. The VM will think the partition is the entire drive and only access the interior boundaries. Stuff like this is harder with a windows guest because it can freak out when booting with different hardware, and by freak out I mean BSOD.
 
Galactic_Dominator said:
Your premise [...] is false. Just map the VM straight the partition. The VM will think the partition is the entire drive and only access the interior boundaries. Stuff like this is harder with a windows guest because it can freak out when booting with different hardware, and by freak out I mean BSOD.
Click to expand...

This would work if I were installing a fresh copy of windows, but then I wouldn't be able to boot it outside of the VM. I have a currently installed copy of Windows, so if I just point it at the slice, it won't boot because the slice doesn't begin with an MBR.
 
That second one shows setting up a VMDK with the MBR in a file and the rest of the device coming from a real device. Be interesting to see if VirtualBox shares that kind of VMDK support.
 
Apparently, the ports maintainer for VirtualBox added support for the [CMD="-relative"][/CMD] flag shortly after I posted this, so using VirtualBox's built in raw disk support for only part of the disk now works. Cool.
 
You must log in or register to reply here.
Back
Top