On 2012-Nov-19 14:38:30 -0700, Mark Shellenbaum <mark.shellenb...@oracle.com> wrote: >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
pgpFsaNn4GfUQ.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
