On 9/7/07, Stephen Usher <[EMAIL PROTECTED]> wrote: > > Brian H. Nelson: > > I'm sure it would be interesting for those on the list if you could > outline the gotchas so that the rest of us don't have to re-invent the > wheel... or at least not fall down the pitfalls.
The UFS on zvols option sounds intriguing to me, but I would guess that the following could be problems: 1) Double buffering: Will ZFS store data in the ARC while UFS uses traditional file system buffers? 2) Boot order dependencies. How does the startup of zfs compare to processing of /etc/vfstab? I would guess that this is OK due to legacy mount type supported by zfs. If this is OK, then dfstab processing is probably OK. I say intriguing because it could give you a the improved data integrity checks and bit more flexibility in how you do things like backups and restores. Snapshots of the zvols could be mounted as other UFS file systems that could allow for self-service restores. Perhaps this would make it so that you can write data to tape a bit less frequently. If deduplication comes into zfs, you may be able to get to a point where course project instructions that say "cp ~course/hugefile ~" become not so expensive - you would be charging quota to each user but only storing one copy. Depending on the balance of CPU power vs. I/O bandwidth, compressed zvols could be a real win, more than paying back the space required to have a few snapshots around. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
