zfs discuss - Jul 2006 - metadata inconsistency?

Hi,
after some unscheduled reboots (to put it lightly), I''ve got an
interesting setup on my notebook''s zfs partition:
setup: simple zpool, no raid or mirror, a couple of zfs partitions, one zvol for
swap. /foo is one such partition, /foo/bar the directory with the issue.

directly after the reboot happened:
$ ls /foo/bar
test.h
$ ls -l /foo/bar
Total 0

the file wasn''t accessible with cat, etc.


somewhat later (new data appeared on /foo, in /foo/baz):
$ ls -l /foo/bar
Total 3
-rw-r--r-- 1 user group 1400 Jul 6 02:14 test.h

the content of test.h is the same as the content of /foo/baz/quux now, but the
refcount is 1!

$ chmod go-r /foo/baz/quux
$ ls -l /foo/bar
Total 3
-rw------- 1 user group 1400 Jul 6 02:14 test.h

good, so at least it''s no security concern.

anyway, how do I get rid of test.h now without making quux unreadable? (the
brute force approach would be a new partition, moving data over with copying -
instead of moving - the troublesome file, just in case - not sure if zfs allows
for links that cross zfs partitions and thus optimizes such moves, then zfs
destroy data/test, but there might be a better way?)


patrick mauritz
 
 
This message posted from opensolaris.org

On Thu, Jul 06, 2006 at 12:46:57AM -0700, Patrick Mauritz
wrote:
> Hi,
> after some unscheduled reboots (to put it lightly), I''ve got an
interesting setup on my notebook''s zfs partition:
> setup: simple zpool, no raid or mirror, a couple of zfs partitions, one
zvol for swap. /foo is one such partition, /foo/bar the directory with the
issue.
> 
> directly after the reboot happened:
> $ ls /foo/bar
> test.h
> $ ls -l /foo/bar
> Total 0
> 
> the file wasn''t accessible with cat, etc.
This can happen when the file appears in the directory listing (ie.
getdents(2)), but a stat(2) on the file fails.  Why that stat would fail
is a bit of a mystery, given that ls doesn''t report the error.

It could be that the underlying hardware has failed, and the directory
is still intact but the file''s metadata has been damaged.  (Note, this
would be hardware error, not metadata inconsistency.)

Another possibility is that the file''s "inode number" is too
large to be
expressed in 32 bits, thus causing a 32-bit stat() to fail.  However,
I don''t think that Sun''s ls(1) should be issuing any 32-bit
stats (even
on a 32-bit system, it should be using stat64).
> somewhat later (new data appeared on /foo, in /foo/baz):
> $ ls -l /foo/bar
> Total 3
> -rw-r--r-- 1 user group 1400 Jul 6 02:14 test.h
> 
> the content of test.h is the same as the content of /foo/baz/quux now,
> but the refcount is 1!
> 
> $ chmod go-r /foo/baz/quux
> $ ls -l /foo/bar
> Total 3
> -rw------- 1 user group 1400 Jul 6 02:14 test.h
This behavior could also be explained if there is an unknown bug which
causes the object representing the file to be deleted, but not the
directory entry pointing to it.
> anyway, how do I get rid of test.h now without making quux unreadable?
> (the brute force approach would be a new partition, moving data over
> with copying - instead of moving - the troublesome file, just in case
> - not sure if zfs allows for links that cross zfs partitions and thus
> optimizes such moves, then zfs destroy data/test, but there might be a
> better way?)
Before trying to rectify the problem, could you email me the output of
''zpool status'' and ''zdb -vvv foo''?  

FYI, there are no cross-filesystem links, even with ZFS.

--matt