Roger, Could you send us (off-list is fine) the output of "truss ls -l <file>"? And also, the output of "zdb -vvv <containing-filesystem>"? (which will compress well with gzip if it's huge.)
thanks, --matt Roger Fujii wrote: > This is on a sol10u3 box. I could boot snv temporarily on this box if it > would accomplish something. > >> Maybe a kernel with a zfs compiled as debug bits would print >> some extra error messages or maybe panic the machine when >> that broken file is accessed? > > Panic? That's rather draconian.... > > Ok... ran zdb on the containing directory, and I see: > > Object lvl iblk dblk lsize asize type > 110733 1 16K 2.50K 2.50K 1K ZFS directory > 264 bonus ZFS znode > path /.spamassassin > atime Thu Aug 9 06:10:16 2007 > mtime Thu Aug 9 06:07:39 2007 > ctime Thu Aug 9 06:07:39 2007 > crtime Fri Oct 6 09:37:52 2006 > gen 25595 > mode 40700 > size 3 > parent 3 > links 2 > xattr 0 > rdev 0x0000000000000000 > microzap: 2560 bytes, 1 entries > > bayes.lock.router.3981 = 8659 > Indirect blocks: > 0 L0 0:134d8b6e00:200 a00L/200P F=1 B=16034915 > > segment [0000000000000000, 0000000000000a00) size 2.50K > > and there is no entry for 8659. (wish zdb was documented somewhere). > I suppose I could just create a gazillion files until it reuses the unused > slot... > (assuming ZFS reuses object #s) :) > > -r > > > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
