[argh. I followed-up using the web interface and sent this message only to -discuss. Carboned back to -help and -bugs here]
I have been able to pin this down a _little_ though I cannot create a simple input dataset for makedbm that triggers the issue. The issue is not a metadisk issue. It appears to be a UFS issue: if I move the directory where the passwd.byuid makedbm writes its output file to a different (non-SVM) UFS filesystem, the system still hangs on the next access by any process to the DBM file's inode (e.g. ls -l in the directory where it's being written). I suspected a problem with transaction logging, but the issue still occurs if I mount the filesystem with "nologging". If I rebuild the test filesystem as a ZFS, the problem does not occur. So I think it is the case that I have a bug in UFS that can hang the entire system -- but no simple, clean way to reproduce it, since I cannot find a test case smaller than "feed the following passwd file to makedbm" (much less one that doesn't involve splatting proprietary information into a bug report). I'd be glad to provide access to the system that exhibits this behavior to Sun folks who want to debug; is there a better way to get in touch, or is this it? This message posted from opensolaris.org
