search for: invalidate_buff

I previously wrote: > I have come across what appears to be a bug in __invalidate_buffers() > w.r.t. the change in ext3-0.0.6 using BH_JDirty instead of BH_Dirty > for buffers held in the journal. If invalidate_buffers() is called > on a device (LVM likes to do this a lot, for whatever reason), it yanks > JDirty buffers out from underneath the journal layer, and causes a...

I previously wrote: > OK, my previous patch cleans up the ASSERT for invalidate_buffers() > (modulo the fact that it was missing a ')' at the end of the line) > but it hasn't really fixed the whole problem. If a file write is in > progress when invalidate_buffers() is called, I get an oops: > The oops is caused from __invalidate_buffers() calling put_last_...

I think I have this one solved, I hope. I think what Andreas and I are running into are a few different assertions. One being the LVM lvm_do_pv_flush caused assertion which is related directly to invalidate_buffers() being called which then triggers refile_buffer() on a journaled buffer, which appears clean in all other ways according to the checks in refile_buffer(). The following is what I've got in __invalidate_buffers() right now. if (!bh->b_count && !buffer_jou...

...there are still buffers being freed from > underneath the journal, without oopsing my machine all the time. I tested the patch, but it didn't seem to help. Basically, I was running a kernel compile, and copying files into a different ext3 filesystem (both on LVs), and running pvscan (i.e. invalidate_buffers) repeatedly. At one point, I got several free buffers reported in cleanup_transaction. After that (this is the first time it happened) my kernel compile deadlocked and the kernel is stuck on: ext3_create journal_start start_this_handle log_wait_for_space log_do_checkpoint cleanup_transaction*...

Hi, I've recently been playing about with recent ext3 0.0.6b and lvm 0.9.1 beta7 and am now able to trigger an "Attempt to refile free buffer" assertion. This seems to "only" occur when using ext3 on the root filesystem. Possibly that is related to the fact that the lvm utility I'm using to reproduce this problem is modifying data in /etc. The easist reproduction

Hi, A system running ext3 crashed this afternoon (nothing to do with ext3, bad network driver). Is was saving a file from emacs when it happened. The file system is 0.06b and had ordered data as the mount option. Let me emphasize this was running ext3 pure, not with SnapFS or InterMezzo layered on top of it. strace reveals that Emacs does open("existing file name", O_TRUNC |