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

[George Hartzell]

Richard Todd writes:
 > On Thu, Jul 18, 2013 at 11:40:51AM -0700, George Hartzell wrote:
 > [...]
 > > [...]  				
 > > In my case I'd want to find a particular set of file size, offset, and
 > > insertion size that triggers the problem and code up a c/c++ equiv. of
 > > the mmap calls that py-mutagen does.  Right?
 > 
 > Yeah. 

I'm stuck.  Or I've discovered something relevant.  Or both.

I've identified a slightly simpler test case.  I load my handful of
test albums, look up single, particular album, and save a particular
track.  The tagged flac file appears to be valid.  Then I reboot.  Now
the flac file is invalid.

It's repeatable, which is useful.

Following the lead of your test script I created a new zfs filesystem,
mounted it, and had picard save the tagged files there.  After exiting
picard the files appears to be valid.  After unmounting and remounting
the filesystem the file *still* appears to be valid.  After rebooting,
the file *still* appears to be valid.

So, it would seem that there's something about the filesystem in which
my home directory resides that contributes to the problem.

The only obvious thing I saw is that my homedir filesystem has a quota
and is 80% full.  I tried creating a new, small, zfs filesystem and
running the test there.  The tagged flac file validates successfully,
I do not see the problem (the single file makes the filesystem 88%
full).

All of the filesystems have automagically created snapshots, so I
tried creating a snapshot of the new zfs filesystem before running
through the test case.  I was still unable to replicate the problem.

My spin on your gen4.cpp test case (modified to use the filesize and
offset that picard uses) does not generate a difference when run in my
home directory followed by a reboot (picard calls insert_bytes twice,
using either set of values does not cause a problem).

The only difference I see in "zfs get all" output (excluding obvious
sizes, etc...) is that the new filesystem has xattr on via the
"default", whereas my home directory has it off via "temporary".  I'm
not sure why it's off.

So, I currently have a repeatable, not-too-efficient test case using
my home directory.  I am unable to repeat the test case using a newly
created zfs filesystem (even a very small one) nor am I able to make
any headway with Richard's test case.

As I described in another thread with Andriy, add INVARIANTS and
INVARIANT_SUPPORT into the kernel did not lead to any different
behaviour, in fact the experiments described above were run on this
new kernel.

Any suggestions for a next step?

g.