similar to: [PATCH -v2 0/3] jbd2 scalability patches

The following 6 patches cleanup the jbd code and kill about 200 lines. First of 4 patches can apply to 2.6.13-git8 and 2.6.13-mm2. The rest of them can apply to 2.6.13-mm2. fs/jbd/checkpoint.c | 179 +++++++++++-------------------------------- fs/jbd/commit.c | 101 ++++++++++-------------- fs/jbd/journal.c | 11 +- fs/jbd/revoke.c | 158

jbd2_journal_restart() would restart a handle. In this function, it calls start_this_handle(). Before calling start_this_handle()?subtract 1 from transaction->t_updates. If start_this_handle() succeeds, transaction->t_updates increases by 1 in it. But if start_this_handle() fails, transaction->t_updates does not increase. So, when commit the handle's transaction in

If we race with commit code setting i_transaction to NULL, we could possibly dereference it. Proper locking requires journal pointer (journal->j_list_lock) we don't have. So we have to change the prototype of the function so that filesystem passes us the journal pointer. Also add more detailed comment about why function does what it does how it should be used. Thanks to Dan Carpenter

This patch contains the following possible cleanups: - make needlessly global functions static - #if 0 the following unused global functions: - journal.c: __journal_internal_check - journal.c: journal_ack_err - remove the following write-only global variable: - journal.c: current_journal - remove the following unneeded EXPORT_SYMBOL's: - journal.c: journal_check_used_features -

From: Jan Kara <jack at suse.cz> If we race with commit code setting i_transaction to NULL, we could possibly dereference it. Proper locking requires the journal pointer (to access journal->j_list_lock), which we don't have. So we have to change the prototype of the function so that filesystem passes us the journal pointer. Also add a more detailed comment about why the function

All, I am running into a situation in which one of my ext3 filesystems is getting hung during normal usage. There are three ext3 filesystems on a CompactFLASH. One is mounted as / and one as /tmp. In my test, I am copying a 100 MB file from /root to /tmp repeatedly. While doing this test, I eventually see the copying stop, and any attempts to access /tmp fail - if I even do ls /tmp the

ocfs2 currently uses the Journaled Block Device (JBD) for its journaling. This is a very stable and tested codebase. However, JBD is limited by architecture to 32bit block numbers. This means an ocfs2 filesystem is limited to 2^32 blocks. With a 4K blocksize, that's 16TB. People want larger volumes. Fortunately, there is now JBD2. JBD2 adds 64bit block number support and some other

As part of migrating the FLUSH/FUA knob to the block layer, remove the journal flags and various conditionals in jbd2 that surround flush issue calls in favor of always issuing the flush. The block layer will handle gracefully the situation where a FLUSH or FUA request is issued to a device that doesn't support it. Signed-off-by: Darrick J. Wong <djwong at us.ibm.com> ---

On Tue, Mar 17, 2009 at 02:02:33PM -0700, Randy Dunlap wrote: > Greg KH wrote: > > On Tue, Mar 17, 2009 at 01:26:47PM -0700, Randy Dunlap wrote: > >> Enable all possible OCFS2 kconfig options: > >> > >> > >> > >> In file included from fs/ocfs2/alloc.c:42: > >> fs/ocfs2/journal.h: In function 'ocfs2_begin_ordered_truncate': >

This patch contains the following possible cleanups: - make needlessly global functions static - journal.c: remove the unused global function __journal_internal_check and move the check to journal_init - remove the following write-only global variable: - journal.c: current_journal - remove the following unneeded EXPORT_SYMBOL's: - journal.c: journal_check_used_features -

This patch contains the following cleanups: - make needlessly global functions static - journal.c: remove the unused global function __journal_internal_check and move the check to journal_init - remove the following write-only global variable: - journal.c: current_journal - remove the following unneeded EXPORT_SYMBOL: - journal.c: journal_recover Signed-off-by: Adrian Bunk

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

Hi, as I mentioned in earlier mail to ext3-users I have been getting some corruption on an ext3 filesystem that has been serving NFS. I am now confident that I fully understand the problem and have a patch. It only affects data=journal mode and I wonder if it might also be the cause of the corruption noted by a number of people on linux-kernel. First I will explain the problem. Then display

Hi Stephen, I'm one of developers of SnapFS, which based on Ext3. I got Assertion failure from SnapFS, at ext3_new_block() in fs/ext3/balloc.c: J_ASSERT (!test_and_set_bit(BH_Alloced, &bh->b_state)) If J_ASSERT is only use as debug, why it will modify data? I found the 'BH_Alloced' flag only occures at two place: one is balloc.c as above, the other is at journal_forget() in

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

Hi all, and particularly Andrew and Stephen, I recently "upgraded' one of my NFS fileservers from (patched)2.4.18 to 2.4.23-pre7 (in order to resolve a HIMEM related memory pressure problem). Unfortunately I have experienced what appears to be a deadlock. The one I will describe was experienced while running 2.4.23-pre7, though I had a very similar problem in 2.4.22 (but

Hello, I've attached the output from "sh scripts/ver_linux" per the bug reporting guidelines, and a diff of the file fs/jbd/transaction.c. At this point, I'm trying to hunt down why some system threads, which are executing the Lustre file system code, are taking an unexpectedly long time executing various ext3 file system functions. I added some debug code to these system

From: Jan Kara <jack at suse.cz> If we race with commit code setting i_transaction to NULL, we could possibly dereference it. Proper locking requires the journal pointer (to access journal->j_list_lock), which we don't have. So we have to change the prototype of the function so that filesystem passes us the journal pointer. Also add a more detailed comment about why the function

I have ext3 0.0.6b + 2.2.19 and cannot get ext3 to compile as a module. If I try to modularize it, or turn in off completely, the kernel build fails. Is there an easy fix for this, or is there something that I am missing? Thanks. Peter

Before we start accessing a huge (> 16 TiB) OCFS2 volume, we need to confirm that its journal supports 64-bit offsets. So we need to check the journal's feature bits before recovering the journal. This is not possible with JBD2 at present, because the journal superblock (where the feature bits reside) is not loaded from disk until the journal is recovered. This patch loads the journal