Thanks for suggesting a broader discussion about the needs and possible uses for specialized storage objects within a pool. In doing so, part of that discussion should include the effect upon overall complexity and manageability as well as conceptual coherence.
In his blog post on ZFS layering (http://blogs.sun.com/bonwick/entry/rampant_layering_violation), Jeff Bonwick articulates the benefits of refactoring the storage stack and eliminating the volume LBA. At the time I bought the argument and I still want it to be so, so it's worth some effort here as well. As I understand it, real ZVOLs are block level access to single DMU objects with full transactional semantics. With those come the ability to snapshot, etc. And with that comes the ability to sit on top of mirrored, raidz/raidz2, or unprotected vdevs. With them also comes some code and memory consumption, I/O ordering, ZIL usage, etc. that could be problematic on the OS dump path and might (or might not) be overkill for swap. Before we name this thing, what is it conceptually? Is it a new kind of DMU object (e.g. a "non-transactional" object?)? A new module on the side of the DMU? A bypass to direct access to the SPA? Direct access to one or more vdevs? Many of these could be possible and perhaps the discussion of possible uses can help choose where it should be done, but the choice does have long-term consequences. Dump and swap certainly pose specialized requirements and historically Unix systems have made pragmatic solutions (e.g. contiguous lvols) in this area. IMHO, it is important enough to have a solution that supports dump and swap in a zpool, that a specialized solution (aka kludge) might be warranted, but I'd like to push hard for at least a short while to see if there is a better cleaner way to do this that avoids making ZFS expose all of the rough edges of past volume managers. A few comments: For swap I think it that some form of data protection (mirroring or raidz) is required. For dump, it would be desirable (and cleaner when all of my zpool is protected) to be able to support mirroring or raidz too. Perhaps there's a problem with why we still configure an OS to have dump and swap *volumes*-- is that time past? Finally, I do not have a solution in mind but I will note that in many ways this reminds me of the problem of bootstrapping the slab allocator and of avoiding allocations when freeing memory objects. When people do cool things in the past, it raises the bar on expectations for the future :). Eric _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
