Pawel Jakub Dawidek wrote: > Hi. > > I've almost all file system functions working. > > I started to run some heavy file system regression tests. They work. fsx > wasn't able to break my port, but the test you can find here: > > http://people.freebsd.org/~kan/fsstress.tar.gz > > broke it. My kernel panics on this assertion (zfs_dir.c): > > 749: mutex_exit(&dzp->z_lock); > 750: > 751: error = zap_remove(zp->z_zfsvfs->z_os, dzp->z_id, dl->dl_name, tx); > 752-> ASSERT(error == 0); > 753: > 754: if (reaped_ptr != NULL) > > zap_remove() returns ENOENT, which is returned because mze_find() > returns NULL. I changed this assertion to printf and I don't see any > other problems with this test-suite - ZFS is stable. > > What I'm looking for is confirmation, that this problem doesn't exist on > Solaris. To verify this someone needs to compile ZFS with debug and run > this test: > > # zpool create tank ... > # fsstress -d /tank/ -n 10000 -p 16 > > This will tell me if this is mine or ZFS's insuffiecient synchronization > somewhere. > > Thanks in advance! >
I tried this on the following systems without tripping the ASSERT. 2 processor opteron 2 processor sparc 4 procssor intel -Mark
