by raattgift » Sun Apr 14, 2013 5:34 pm
That's short hand for "there are gotchas" beyond having to know how to import a pool with file devices, knowing how the names of the files themselves will be treated if moved from the precise environment in which they were created, being aware of filesystems which compress or sparseify files or which do not offer POSIX semantics or which are deficient with respect to durability guarantees, all of which can lead to data in the pool becoming temporarily or permanently unavailable, and in some cases may cause a system to crash.
Most of those issues affect all implementations of ZFS, which has always implemented files as first class vdev components, but which has always warned people against using them without explaining why in great detail. Most of it boils down to: configuring is easy; configuring well not so much; maintaining even less so. Also, performance is not going to be very good, especially if the files live in a filesystem that does lots of metadata updates (atimes, zfs internal metadata, etc.), which does not match the pool's ashift, or which does its own checksumming and compression.
ZEVO-specific caveats are likely limited to (a) the dynamic name allocation systems in Mac OS X and (b) the performance impact on the small ARC and vnode/dnode/znode spaces. (a) will probably bite someone doing a zpool import.
All this considered, the position stated on the wiki page is reasonable. Personally, I would say, "it works fine, we use it ourselves, but there are lots of ways to do the wrong thing, and if you do any of those it's your problem not ours; don't call us or call us names if you use file-based vdevs and hit problems, even if it works fine in OI or OS".
Incidentally, "file-based vdev" is an awkward way of putting it. Is a 3-sided mirror vdev with two physical disks and one file a "file-based vdev"? Or does "file-based vdev" mean a vdev that is only one file? (Guess: yes, no).