Date: Fri, 19 Jul 2013 10:27:31 -0700 From: George Hartzell <hartzell@alerce.com> To: Richard Todd <rmtodd@servalan.servalan.com> Cc: freebsd-stable@freebsd.org, George Hartzell <hartzell@alerce.com> Subject: Re: Help with filing a [maybe] ZFS/mmap bug. Message-ID: <20969.30467.601461.313726@gargle.gargle.HOWL> In-Reply-To: <20130718192624.GA45917@ichotolot.servalan.com> References: <20967.760.95825.310085@gargle.gargle.HOWL> <x7vc48sb5e.fsf@ichotolot.servalan.com> <20968.14003.813473.517439@gargle.gargle.HOWL> <20130718192624.GA45917@ichotolot.servalan.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20969.30467.601461.313726>