On Wed, Sep 22, 2010 at 20:15, Markus Kovero <markus.kov...@nebula.fi> wrote: > > >> Such configuration was known to cause deadlocks. Even if it works now (which >> I don't expect to be the case) it will make your data to be cached twice. >> The CPU utilization > will also be much higher, etc. >> All in all I strongly recommend against such setup. > >> -- >> Pawel Jakub Dawidek http://www.wheelsystems.com >> p...@freebsd.org http://www.FreeBSD.org >> FreeBSD committer Am I Evil? Yes, I Am! > > Well, CPU utilization can be tuned downwards by disabling checksums in inner > pools as checksumming is done in main pool. I'd be interested in bug id's for > deadlock issues and everything related. Caching twice is not an issue, > prefetching could be and it can be disabled > I don't understand what makes it difficult for zfs to handle this kind of > setup. Main pool (testpool) should just allow any writes/reads to/from > volume, not caring what they are, where as anotherpool would just work as any > other pool consisting of any other devices. > This is quite similar setup to iscsi-replicated mirror pool, where you have > redundant pool created from iscsi volumes locally and remotely.
ZFS needs free memory for writes. If you fill your memory with dirty data zfs has to flush that data to disk. If that disk is a virtual disk in zfs on the same computer those writes need more memory from the same memory pool and you have a deadlock. If you write to a zvol on a different host (via iSCSI) those writes use memory in a different memory pool (on the other computer). No deadlock. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
