From owner-freebsd-stable@FreeBSD.ORG Wed Jul 24 16:47:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C1835CED for ; Wed, 24 Jul 2013 16:47:11 +0000 (UTC) (envelope-from hartzell@alacrity.alerce.com) Received: from griffon.alerce.com (griffon.alerce.com [206.125.171.162]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B03C2CAD for ; Wed, 24 Jul 2013 16:47:11 +0000 (UTC) Received: from griffon.alerce.com (localhost [127.0.0.1]) by griffon.alerce.com (Postfix) with ESMTP id 3A9742842A; Wed, 24 Jul 2013 09:47:01 -0700 (PDT) Received: from alacrity.alerce.com (75-149-38-78-SFBA.hfc.comcastbusiness.net [75.149.38.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by griffon.alerce.com (Postfix) with ESMTPSA id DCD1C28424; Wed, 24 Jul 2013 09:47:00 -0700 (PDT) Received: by alacrity.alerce.com (Postfix, from userid 503) id 830E715478DF; Wed, 24 Jul 2013 09:46:57 -0700 (PDT) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20976.1281.477385.398891@gargle.gargle.HOWL> Date: Wed, 24 Jul 2013 09:46:57 -0700 To: hartzell@alerce.com Subject: Re: Help with filing a [maybe] ZFS/mmap bug. In-Reply-To: <20972.12828.973631.17998@gargle.gargle.HOWL> References: <20967.760.95825.310085@gargle.gargle.HOWL> <20968.14003.813473.517439@gargle.gargle.HOWL> <20130718192624.GA45917@ichotolot.servalan.com> <20969.30467.601461.313726@gargle.gargle.HOWL> <20969.35970.217377.274868@gargle.gargle.HOWL> <20972.12828.973631.17998@gargle.gargle.HOWL> X-Mailer: VM 8.2.0b under 24.2.1 (x86_64-apple-darwin) X-Virus-Scanned: ClamAV using ClamSMTP Cc: Richard Todd , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: hartzell@alerce.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 16:47:11 -0000 George Hartzell writes: > > George Hartzell writes: > > George Hartzell writes: > > > [...] > > > So, it would seem that there's something about the filesystem in which > > > my home directory resides that contributes to the problem. > > > [...] > > > > Another data point. > > > > [...] > > Yet another data point or three. > > I took an unused disk, set it up with a single pool and copied > everything from my two disk system to it using zfs send & recv. I was > hoping that if there was something goofy about the state of the > filesystems on the older two disk pool it might get cleaned up in the > transfer. > > I tagged the entire set of flac files, they were all successfully > validated via the plugin. After exiting Picard, one failed > validation. After rebooting, many failed validation. > > Next I created a new filesystem on this new pool, mounted it, > configured Picard to save to that filesystem and ran through all of > the tracks. They validated fine via the plugin and by hand after > exiting Picard. They also validated properly after unmounting and > remounting the filesystem and after a reboot. Sigh. > > Then I destroyed all of the snapshots on the filesystems that I > transfered over from my "real" dual-disk system. Tagging all of the > flac files into my home directory generated errors from the validation > plugin and by hand after exiting picard. I didn't bother rebooting > and checking. > > So it seems to be something about the filesystem{s} themselves. > [...] A [small] breakthrough. I understand why saving to a freshly created filesystem never led to any errors. I'd tentatively concluded that there was something hinky with the filesystem itself that was causing the problem, something that came along when I recreated the filesystem via zfs send/recv. This was based on my inability to trigger the problem when I saved the files to a newly created zfs filesystem. Yesterday I used dump and restore to transfer my trouble-free home directory from its UFS partition to a newly created zfs filesystem (I hadn't know that restore would write to a zfs filesystem but it appears to...). The resulting system generated errors when I ran through my "test case", even though it wasn't a zfs send/recv copy. Next I created a new zfs filesystem and arranged to write the tagged files there. The resulting files were error free, even after a reboot. Next I copied the untagged source flacs onto the newly created zfs filesystem and ran through the test routine, saving the tagged files to the newly created zfs filesystem. This resulted in a glorious pile of errors. Conclusion: my test case only generates errors when the untagged files are on the fileysystem to which the tagged files will be written. A bit of poking around in the sources provided the explanation. Picard tries to move the tagged file to its final destination. If it's within the same filesystem this ends up being a rename operation and I'm left with the inconsistent flac file. If the destination is in another fileysystem then it copies the file, which ends up reading the clean memory-resident data. So, now I have a smaller test version of my workflow that doesn't involve rebooting my machine to generate the error. I'll get back to trying to come up with a variant of Richard's stand alone bug-tickler. phew. g.