similar to: Re: Bug in __invalidate_buffers?

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 an > oops

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_free(bh) >

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

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

Hello. I found bugs on error handlings in the functions arround the ext3 file system, which cause inadequate completions of synchronous write I/O operations when disk I/O failures occur. Both 2.4 and 2.6 have this problem. I carried out following experiment: 1. Mount a ext3 file system on a SCSI disk with ordered mode. 2. Open a file on the file system with O_SYNC|O_RDWR|O_TRUNC|O_CREAT

>From nfs-admin@lists.sourceforge.net Thu Feb 1 03:51:36 2001 >Return-Path: <nfs-admin@lists.sourceforge.net> Received: from usw-sf-list1.sourceforge.net (usw-outbound.sourceforge.net [216.136.171.194]) by gateway.camelot.jp (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id DAA11596 for <jareth@camelot.co.jp>; Thu, 1 Feb 2001 03:51:35 +0900 X-Authentication-Warning:

Hello, I was wondering if we can get some help in resolving this bug. It was reported earlier and logged in bugme.osdl.org http://bugme.osdl.org/show_bug.cgi?id=4683 The problem is kernel oops at log_do_checkpoint() due to NULL buffer_head. This could be because of some race in journalling code for which I don't have much clue. There is kdump available for analysis as mentioned in the

A little bugfix delta. I don't believe there is a need for x86 users to upgrade. http://www.uow.edu.au/~andrewm/linux/ext3/ - Fix unaligned access on Alpha - Fix build with CONFIG_JBD=n - Speed up log_do_checkpoint() - significant benefits for journalled data mode. - Fix possible oops in log_do_checkpoint(). - Comment out unused journal_release_buffer().

My manual patching of the rejects in checkpoint.c didn''t work out; a delete of 10,000 files caused a panic (in any ext fs, not just Lustre). In the new checkpoint.c, two routines expected by the patch no longer exist: __cleanup_transaction and __flush_buffer. I can avoid the panic if I omit (don''t try to manually patch) the following: Index: linux-2.6.9/fs/jbd/checkpoint.c

Al writes: > On Thu, 22 Mar 2001, Andreas Dilger wrote: > > If this is the case, then all of the other zero initializations can be > > removed as well. I figured that if most of the fields were being > > zeroed, then ones _not_ being zeroed would lead to this problem. > > Other zero initializations in inode->u certainly can be > removed, but whether it's

This caused a crash on a 2.6.10-1.12_FC2smp kernel May 19 09:56:35 spf1 kernel: Assertion failure in log_do_checkpoint() at fs/jbd/checkpoint.c:361: "drop_count != 0 || cleanup_ret != 0" May 19 09:56:35 spf1 kernel: ------------[ cut here ]------------ May 19 09:56:37 spf1 kernel: kernel BUG at fs/jbd/checkpoint.c:361! May 19 09:56:37 spf1 kernel: invalid operand: 0000 [#1] May 19

I'm looking for some recommendations on where to go with a problem i'm running across. A filesystem under load put itself in readonly mode and the following can be found under dmesg.. any suggestions on root cause? hardware wise it's got a pair of PATA drives connected to a 3ware card in RAID10 configuration. EXT3-fs error (device dm-4): ext3_add_entry: bad entry in directory

Hi, We are running a server as an nfs head connect to a clariion, every couple of days we have our box fall over with the following msg in syslog. Has anyone had this happen to there boxen? rhel4 u4 May 8 12:23:52 ruchba kernel: Assertion failure in log_do_checkpoint() at fs/jbd/checkpoint.c:363: "drop_count != 0 || cleanup_ret != 0" May 8 12:23:52 ruchba kernel: ------------[ cut

While compiling two kernels and untarring a third, my root fs was remounted r/w and I got the following in dmesg (kernel 2.4.19-pre9): EXT3-fs error (device ide0(3,2)) in ext3_new_inode: error 28 Aborting journal on device ide0(3,2). ext3_abort called EXT3-fs abort (device ide0(3,2)): ext3_journal_start: Detected aborted journal. Remounting filesystem read-only Remounting filesystem read-only

From: Wang Shilong <wangsl.fnst@cn.fujitsu.com> Scrubing supers is not in a transaction context, when trying to write supers to disk, we should check if we are trying to scrub supers.Fix it. Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com> --- fs/btrfs/disk-io.c | 2 ++ fs/btrfs/transaction.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/fs/btrfs/disk-io.c

A change was made to ext3 in 2.4.20-pre9 which will cause the filesystem to run ext3_mark_inode_dirty() against a freed inode. This will occur when an application attempts to add a new file/directory to the filesystem and encounters space or inode exhaustion. The results of this are unpredictable. Usually, nothing happens. But it can cause random memory corruption on SMP, and the kernel will

Hi Andreas, Stephen, We have a lot working now: 1. journal recovery and initialization stuff is working 2. transactions go to the disk 3. infrastructure is there to do transcactions 4. ext3_create is fully operational. The problems we have seen mostly have to do with differences in which buffer heads are being initialized. Things like b_transaction etc. were not cleaned up. There are more

Dear xen-users, in the last two days, two different domUs on two different dom0s had suddenly corrupted filesystems which let to total data loss on both domUs. I have never suffered under this failure before and I guess it is related to XEN. Both domUs were running for long time without any problems and I am pretty sure, that the hard drives are fine (checked with smart checks).

Hi, I have a server configured as follows: a standard 2.4.18 kernel, IDE discs, 1Gb RAM (not all used), load avg around 1-2. a large partition, formatted reiserfs within large partition are 80 300Mb loopback file systems, formatted ext3. I got the following assertion yesterday which forced a lot of processes into D state. I'm not sure how easy it is to reproduce this problem.

On Apr 29, 2004 14:15 +0200, David Mart?nez Moreno wrote: > Hello all. I'm writing to all the people in charge of ext3 fs > > Apr 29 12:21:21 arsinoe kernel: EXT3-fs error (device sda7): ext3_free_blocks: Freeing blocks not in datazone - block = 1071716394, count = 1 You need to run "e2fsck -f /dev/sda7" on the unmounted filesystem. There is some sort of corruption