ZFS checksum errors on USB attach (Was: ZFS data error without reasons)

[Norikatsu Shigemura]

Hi jhb!

	I got ZFS checksum error issue, too.  So I found a way of fixing
	this issue.  Please back out following change.

sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
revision 1.5
date: 2009/03/18 16:19:44;  author: jhb;  state: Exp;  lines: +2 -0
SVN rev 189967 on 2009-03-18 16:19:44Z by jhb

The zfs_get_xattrdir() function is used to find the extended attribute
directory for a znode.  When the directory already exists, it returns a
referenced but unlocked vnode.  When a directory does not yet exist, it
calls zfs_make_xattrdir() to create a new one.  zfs_make_xattrdir() returns
the vnode both referenced and and locked and zfs_get_xattrdir() was leaking
this vnode lock to its callers.  Fix this by dropping the vnode lock if
zfs_make_xattrdir() successfully creates a new extended attribute
directory.

Reviewed by:    pjd
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

	[Validation]
	1. I got ZFS checksum error issue
	2. Backup
	3. Restructure ZPool
	4. Restore (But ZFS checksum error)
	5. Restructure ZPool with kern.smp.disabled=1
	   (Almost good, but...)
	6. Restore
	7. Backout zfs_dir#1.5
	8. Good works for me

	I tested many backup&restore:-).

On Mon, 6 Apr 2009 23:26:57 +0100
"Thomas Sparrevohn" <Thomas.Sparrevohn at btinternet.com> wrote:
> Just a me too - Here - I just seen significant corruption of a newly
> restored pool - the system had been running a portupgrade - I am getting
> worried - but the disks shows no errors - neither from the ATA subsystem nor
> from smartctl or some vendor testing tools I have 

> -----Original Message-----
> From: owner-freebsd-current at freebsd.org
> [mailto:owner-freebsd-current at freebsd.org] On Behalf Of Damian Gerow
> Sent: 05 April 2009 02:56
> To: freebsd-current at freebsd.org
> Subject: Re: ZFS checksum errors on USB attach (Was: ZFS data error without
> reasons)
> I've filed kern/133373 to track this.