On Wed, 03 Jan 2007 22:56:07 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]> > Date: Wed, 3 Jan 2007 22:12:20 -0800 > > > On Thu, 04 Jan 2007 17:03:43 +1100 > > Nick Piggin <[EMAIL PROTECTED]> wrote: > > > > > > That bug was introduced in 2.6.19, with the dirty page tracking patches. > > > > > > > > 2.6.18 and earlier used ->private_lock coverage in > > > > try_to_free_buffers() to > > > > prevent it. > > > > > > Ohh, right you are, I was looking at 2.6.19 sources. The comments above > > > ttfb match that as well. Curious that the dirty page patches were allowed > > > to mess with this... > > > > Frankly, those patches scared the crap out of me, specifically because of > > the delicacy and complexity of the various dirtiness state coherencies. > > But I just didn't have the bandwidth to go through them with a sufficiently > > fine toothcomb, sorry. > > > > > Anyway that leaves us with the question of why Andrea's database is > > > getting > > > corrupted. Hopefully he can give us a minimal test-case. > > > > It'd odd that stories of pre-2.6.19 BerkeleyDB corruption are now coming > > out of the woodwork. It's the first I've ever heard of them. > > Note that the original rtorrent debian bug report was against 2.6.18 I think that was 2.6.18+debian-added-dirty-page-tracking-patches. If that memory is correct, I'll assert (and emphasise) that the cause of the alleged BerkeleyDB corruption is not known at this time. The post-2.6.19 "fix" might make it go away. But if it does, we do not know why, and it might still be there, only harder to hit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
