These problems both occur when accessing a ZFS dataset from Linux (FC10) via NFS. Jigdo is a fairly new bit-torrent-like downloader. It is not entirely bug free, and the one time I tried it, it recursively downloaded one directory''s worth until ZFS eventually sort of died. It put all the disks into error, and even the (UFS) root disks became unreadable. It took a reboot to free everything up and some twiddling to get ZFS going again. I really don''t want to even try to reproduce this! With 4GB physical, 10GB swap, and almost 3TB of raidz, it probably didn''t run out of memory or disk space. There wasn''t room on the boot disks to save the crash dump after halt, sync. Is there any point in submitting a bug report, and if so, what would you call it? Is there a practical way to force the crash dump to go to a ZFS dataset instead of the UFS boot disks? Also, there is a reasonably reproducible problem that causes a panic doing an NFS network install when the DVD image is copied to a ZFS dataset on snv103. I submitted this as a bug report to bugs.opensolaris.org, and it was acknowledged, but then it vanished. This is actually an NFS/ZFS problem, so maybe it was applied against the wrong group, or perhaps this was a transition issue. I wasn''t able to get a crash core saved because there wasn''t enough space on the boot (UFS) disks. I do have the panic traces for the 3 times I reproduced this. Should this be resubmitted to defect.opensolaris.org, and if so, against what? This problem doesn''t happen of the DVD image is itself mounted via NFS, or is on a UFS partition.