Help with filing a [maybe] ZFS/mmap bug.

[George Hartzell]

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.