I managed to create a link in a ZFS directory that I can''t remove. Session as follows: # ls bayes.lock.router.3981 bayes_journal user_prefs # ls -li bayes.lock.router.3981 bayes.lock.router.3981: No such file or directory # ls bayes.lock.router.3981 bayes_journal user_prefs # /usr/sbin/unlink bayes.lock.router.3981 unlink: No such file or directory # find . -print . ./bayes_journal find: stat() error ./bayes.lock.router.3981: No such file or directory ./user_prefs # ZFS scrub shows no problems in the pool. Now, this was probably cause when I was doing some driver work so I''m not too surprised, BUT it would be nice if there was a way to clean this up without having to copy the filesystem to a new zfs filesystem and destroying the current one. Any suggestions anyone? Thanks. -r This message posted from opensolaris.org
Roger Fujii wrote:> I managed to create a link in a ZFS directory that I can''t remove. Session as follows: > > # ls > bayes.lock.router.3981 bayes_journal user_prefs > # ls -li bayes.lock.router.3981 > bayes.lock.router.3981: No such file or directory > # ls > bayes.lock.router.3981 bayes_journal user_prefs > # /usr/sbin/unlink bayes.lock.router.3981 > unlink: No such file or directory > # find . -print > . > ./bayes_journal > find: stat() error ./bayes.lock.router.3981: No such file or directory > ./user_prefs > #make sure you have no unprintable characters in the file name (eg. with a command like ls -las | od -c or some such) HTH Michael -- Michael Schuster Sun Microsystems, Inc. Recursion, n.: see ''Recursion''
I guess I should have included this output too: # ls -al total 124 drwx------ 2 rmf other 5 Aug 9 05:26 . drwx--x--x 148 rmf other 283 Aug 9 05:40 .. -rw------- 1 rmf other 26616 Apr 16 00:17 bayes_journal -rw------- 1 rmf other 1938 Apr 15 04:03 user_prefs This isn''t an unprintable character thing - find would not report errors because of that (I would have never seen this if find didn''t spew out the error). It''s definitely a directory entry that doesn''t point to anything. It''s really in this funny state that various things think something is there, and others don''t think something is there at all. # ls bayes.lock.router.3981 bayes_journal user_prefs # touch bayes.lock.router.3981 touch: bayes.lock.router.3981 cannot create # rm bayes.lock.router.3981 bayes.lock.router.3981: No such file or directory # touch test # ln test bayes.lock.router.3981 ln: cannot create link bayes.lock.router.3981: File exists # pwd /home/rmf/.spamassassin # cd .. # rm -r .spamassassin bayes.lock.router.3981: No such file or directory rm: Unable to remove directory .spamassassin: File exists The filesystem gods do taunt me... :) -r This message posted from opensolaris.org
> I managed to create a link in a ZFS directory that I can''t remove. > > # find . -print > . > ./bayes_journal > find: stat() error ./bayes.lock.router.3981: No such > file or directory > ./user_prefs > # > > > ZFS scrub shows no problems in the pool. Now, this > was probably cause when I was doing some driver work > so I''m not too surprised, BUT it would be nice if > there was a way to clean this up without having to > copy the filesystem to a new zfs filesystem and > destroying the current one.Are you running an opensolaris using release or debug kernel bits? 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? This message posted from opensolaris.org
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
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 at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss