I think in the case of swap and preserving the no-partitioning thing, ZFS would need support either of these:
- The easier of the two, the ability to disable COW on ZVOLs, for performance reasons i.e. with swap. Also, if you are willing to trade off reliability for performance. - The harder of the two, the ability to punch a hole into the zpool, which can be used for swap like a block device, bypassing most of ZFS' code (apart from the RAID-Z/mirror block allocator code, I'd guess). While for a home user, it wouldn't make much difference if one disk (alone or in an unredundant JBOD (aka RAID-0)) is sliced to supply swap, but if you're introducing RAID-Z or mirrors, you'll lose the size of swap multiplied by the amount of disks affected. For instance, two gigabytes swap in a four disk RAID-Z pool results in six gigabytes lost. Hole punching would claim 512 megabytes on each device and the RAID-Z allocator would spread the blocks accordingly, but not doing parity. Then again, eight gigabytes on a fairly huge RAID-Z is peanuts, but the write caches would still be disabled with slicing. Just an idea, anyway. -mg > Swap on ZFS is possible, but I myself would say, a > plain slice on the > disk without a ZFS-Block-Device should be faster, > since ZFS/ZFS-Blockdevice > is no extra layer in this case. We should ask the ZFS > peoples about the > difference in performance between a plain disk slice > and a ZFS Block-Device. -- This message posted from opensolaris.org _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
