On 2012-Nov-19 14:38:30 -0700, Mark Shellenbaum <mark.shellenb...@oracle.com> 
>On 11/19/12 1:14 PM, Jim Klimov wrote:
>> On 2012-11-19 20:58, Mark Shellenbaum wrote:
>>> There is probably nothing wrong with the snapshots.  This is a bug in
>>> ZFS diff.  The ZPL parent pointer is only guaranteed to be correct for
>>> directory objects.  What you probably have is a file that was hard
>>> linked multiple times and the parent pointer (i.e. directory) was
>>> recycled and is now a file

Ah.  Thank you for that.  I knew about the parent pointer, I wasn't
aware that ZFS didn't manage it "correctly".

>The parent pointer for hard linked files is always set to the last link 
>to be created.
>$ mkdir dir.1
>$ mkdir dir.2
>$ touch dir.1/a
>$ ln dir.1/a dir.2/a.linked
>$ rm -rf dir.2
>Now the parent pointer for "a" will reference a removed directory.

I've done some experimenting and confirmod this behaviour.  I gather
zdb bypasses ARC because the change of parent pointer after the ln(1)
only becames visible after a sync.

>The ZPL never uses the parent pointer internally.  It is only used by 
>zfs diff and other utility code to translate object numbers to full 
>pathnames.  The ZPL has always set the parent pointer, but it is more 
>for debugging purposes.

I didn't realise that.  I agree that the above scenario can't be
tracked with a single parent pointer but I assumed that ZFS reset the
parent to "unknown" rather than leaving it as a pointer to a random
no-longer-valid object.

This probably needs to be documented as a caveat on "zfs diff" -
especially since it can cause hangs and panics with older kernel code.

Peter Jeremy

Attachment: pgpFsaNn4GfUQ.pgp
Description: PGP signature

zfs-discuss mailing list

Reply via email to