Date: Thu, 18 Jul 2013 22:10:22 +0300 From: Alexander Yerenkow <yerenkow@gmail.com> To: hartzell@alerce.com Cc: Richard Todd <rmtodd@servalan.servalan.com>, FreeBSD Stable Mailing List <freebsd-stable@freebsd.org> Subject: Re: Help with filing a [maybe] ZFS/mmap bug. Message-ID: <CAPJF9wn-ysK3q=W4%2BxhUe5qEnXpMhTY3SVjmm-PxotZCFcdA%2Bw@mail.gmail.com> In-Reply-To: <20968.14003.813473.517439@gargle.gargle.HOWL> References: <20967.760.95825.310085@gargle.gargle.HOWL> <x7vc48sb5e.fsf@ichotolot.servalan.com> <20968.14003.813473.517439@gargle.gargle.HOWL>
next in thread | previous in thread | raw e-mail | index | archive | help
I know how all not loving "me-too" emails, but I'll try :) There's a rtorrent, which uses mmap. And I had cases (related to reboot), where big files (or average files in many-files torrents) appears with broken checksum without any good reason. Author of rtorrent not very politely always assume that really broken other filesystems, while rtorrent have simple logic (with mmap using)... This post is pretty interesting: http://libtorrent.rakshasa.no/ticket/483 In the end I just switched to transmission. Anyway, there could be really some weird/rare bugs with ZFS and mmap. Or just ZFS. I hope this will help at least to narrow direction for potential bugbusting. 2013/7/18 George Hartzell <hartzell@alerce.com> > Richard Todd writes: > > George Hartzell <hartzell@alerce.com> writes: > > > > > Hi All, > > > > > > I have what I think is a ZFS related bug. > > > [...] > > > > [summary: Picard seems to trigger an mmap consistency bug in ZFS]. > > > > [...] > > Anyway, what I'd suggest is the following: see if my patch for > py-mutagen > > disabling the mmap() in those two functions lets you run picard > reliably. > > Removing the mmap support from those two routines seems to avoid the > issue. > > > If so, then the issue is triggered by one or both of those two routines; > > hack them to print out the exact offsets used on each call and use that > to > > try and code up a simple C++ test case. > > [...] > > Your test case doesn't use mmap, I assume that you've offered it up as > a hint, not as something that's nearly done. The shell script in > particular seems useful. > > 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? > > I'm hesistant about that. I believe (and will try to prove) that the > problem does not occur deterministically for a particular track > between different test runs. I'm worried that it's not as simple as > "using mmap to insert 27 bytes into a 1024 bytes file at pos 42 causes > corruption" but rather that it depends on a more complex set of > interactions. > > My next step will be to see if a track that has trouble in one run has > trouble in another. If not, then I'm not sure that a simple test will > be successful. > > g. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Regards, Alexander Yerenkow
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPJF9wn-ysK3q=W4%2BxhUe5qEnXpMhTY3SVjmm-PxotZCFcdA%2Bw>