raattgift wrote:Finally, there is likely a limit to the arbitrariness of the files; I wouldn't want to use vdevs whose files live in a FAT filesystem, for instance, nor would I want to use a pool with double-digit numbers of files let alone anything approaching the number of band files in a nontrivial sparsebundle.
What is your concern about sparsebundles? They seem quite robust to me, especially since their purpose in life is to be the backing store for network-based backups.
Do you have the same concern about using sparseimage files?
And in terms of what you do think makes sense, do you prefer the use of a file made using dd, using mkfile, a dmg, a sparseimage, or something else?
Another approach would be to use, VMware as a hybrid solution. As far as ZEVO running inside an OS X VM is concerned, it is using real hard drives, which are in fact vmdks. You also have the option to use monolithic preallocated disks, which are really two files: a Virtual Disk.vmdk and a Virtual Disk-flat.vmdk, the former containing the configuration information for the disk, the latter being the actual "disk." You can even dd the flat file onto a real disk, provided you know how to navigate the partitioning issues.
**And you can still achieve replication by implementing mirrors or raidz/2/3 over multiple vmdks.**
This method seems to improve portability and to deal with the persistent naming issues, not to mention opening up the possibility of using VMware snapshots. And VMware Fusion 5 has built in support for enabling encryption of your VM, so you don't have to sacrifice the native encryption that sparsebundles offer.
Also, it is worth mentioning, of course, that it is standard practice to use virtual disks serving as "physical" vdevs in VirtualBox running Oracle Solaris.
Here is what a VMware preallocated virtual disk looks like under the hood (bonnet):
- Code: Select all
Josephs-MacBook-Pro:vmdk-vdevs joe$ ls
ZEVOvdev0-flat.vmdk ZEVOvdev0.vmdk
Josephs-MacBook-Pro:vmdk-vdevs joe$ cat ZEVOvdev0.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
isNativeSnapshot="no"
createType="monolithicFlat"
# Extent description
RW 4194304 FLAT "ZEVOvdev0-flat.vmdk" 0
# The Disk Data Base
#DDB
ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "261"
ddb.uuid = "60 00 C2 9b db dc aa 18-94 c5 03 bb 18 1a 5c 69"
ddb.longContentID = "7dcc7a56d31434334076aed6fffffffe"
ddb.virtualHWVersion = "9"
Josephs-MacBook-Pro:vmdk-vdevs joe$ hexdump -C ZEVOvdev0-flat.vmdk
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
80000000
Josephs-MacBook-Pro:vmdk-vdevs joe$
Be sure to use the tools in /Applications/VMware\ Fusion.app/Contents/Library/ when dealing with these disks. For example, you do renaming like this:
- Code: Select all
Josephs-MacBook-Pro:vmdk-vdevs joe$ ls -l
total 4194312
-rw------- 1 joe staff 2147483648 Apr 14 21:52 Virtual Disk-flat.vmdk
-rw------- 1 joe staff 483 Apr 14 23:52 Virtual Disk.vmdk
Josephs-MacBook-Pro:vmdk-vdevs joe$ /Applications/VMware\ Fusion.app/Contents/Library/vmware-vdiskmanager -n Virtual\ Disk.vmdk ZEVOvdev0.vmdk
Renaming completed successfully.
Josephs-MacBook-Pro:vmdk-vdevs joe$ ls -l
total 4194312
-rw------- 1 joe staff 2147483648 Apr 14 21:52 ZEVOvdev0-flat.vmdk
-rw------- 1 joe staff 480 Apr 14 23:52 ZEVOvdev0.vmdk
Josephs-MacBook-Pro:vmdk-vdevs joe$
Notice the change in size of Virtual Disk.vmdk from 483B to 480B, since vmware-vdiskmanager has updated the info inside the file in addition to renaming it.
Another benefit to leveraging VMware is that you can choose to use preallocated virtual disks split in 2GB file, which is similar to a sparsebundle, but avoids the massive number of small files.
However, it is worth noting that the hdiutil man page says
HDIUTIL(1) wrote: By default, UDSP images grow one megabyte at a time.
Introduced in 10.5, UDSB images use 8 MB band files
which grow as they are written to. -imagekey
sparse-band-size=size can be used to specify the
number of 512-byte sectors that will be added each
time the image grows. Valid values for SPARSEBUNDLE
range from 2048 to 16777216 sectors (1 MB to 8 GB).
So actually, I think it is possible to avoid the massive number of small band files if you opt to use sparsebundles.