similar to: ext3_free_data()

[Re-sending to the ext3 list, with minor edits] I'm in the process of fixing errors generated by the Coverity tool on the Linux kernel, and I would like your comment on a set of problems reported in ext3. The main issue reported is not checking the return code of ext3_journal_get_write_access() in various places. I would like to know if there should be error handling in these cases. The

Hello ext3-users, I tested ext3 on a Linux for S/390 with several stress and benchmark test tests and faced a kernel bug message. The console showed the following output: Message from syslogd@boeaet34 at Fri Aug 3 11:34:16 2001 ... boeaet34 kernel: Assertion failure in journal_forget() at transaction.c:1184: "! jh->b_committed_data" I tried the Patch from

Hi, I got the OOPS below on my laptop running vanilla 2.4.20-ac2; I had to copy it byhand so it may not be 100% accurate. It hasn't happened again, and this is the first problem I've had with this kernel (or any other kernel, for that matter.) Anyway, I'm not sure, if a) this is actually an ext3 problem, b) OOPS reports of 2.4.20-ac2 are of any interest, so I won't bother with

Hi Stephen, I found a bug in JBD routine journal_create() in kernel 2.6, when I debug the OCFS v2 driver. mark_buffer_dirty() reports buffer_head is not uptodate. See following bug description. ------------------------------------------------------- OS: Linux Kernel 2.6.1 Plarform: IA32 Steps: 1. Build the ocfs v2 driver under kernel 2.6. 2. insert ocfs2.ko into kernel 2.6. 3. mkfs.ocfs2 -F

Hello ext3-developers, Just to summarize, I reported a kernel bug message with ext3 on S/390 in transaction.c. I was able to reproduce it with a ext3 on LVM and on MD. Tom Rini reported a similar problem on PPC. (both big endian). I have sent a backtrace and with jbd-debug set to 5 I was not able to reproduce the problem until now. On S/390 there are some more debug possibilities. I would

I recently rebooted one of my machines and was greeted with a message about one of my ext3 partitions having some errors. I dutifully started e2fsck on the partition, but after a few hours of some useful messages about fixing inodes, it then started printing out lists of ascending numbers which I'm not sure how to interpret. The first time I noticed this, these numbers were in the 4000000

All, I know that there is no official port to Kernel 2.4.4, thus I may not get any help, however I am hoping someone could point me in the right direction for my problem. I am currently forced to use kernel 2.4.4 for reasons out of my control (embedded board). Here are the exact versions of everything I'm running: ExT3 Version: ext3-2.4-0.9.6-248 Util Version: util-linux-2.11f.tar.bz2 e2fs

This fixes the "i_blocks went wrong when the disk filled up" problem. In ext3_new_block() we increment i_blocks early, so the quota operation can be performed outside lock_super(). But if the block allocation ends up failing, we forget to undo the allocation. This is not a serious bug, and probably does not warrant an upgrade for production machines. Its effects are: 1) errors are

Hello, I have today released an initial version of extended attributes and access control lists for ext3 (patch against the 2.4.13-ac3 kernel). Eric Jarman <ejarman@acm.org> has contributed a lot to this effort. Since I'm not very much into the innards of ext3, can some of you please take a look at the patch, and see whether it contains any flaws (and tell me which flaws)? Thanks! The

Hello! This is Kernel 2.4.6-ac1 with ext3-0.8.0 compiled with cvs-gcc version 3.1 20010616 on alpha ev4. I have prepared one ext3 filesystem to play with. When my rc-scripts call mount -a during boot I receive this: Jul 6 22:01:30 Marvin kernel: Bad unaligned kernel access at fffffc0000883f54: fffffc00063f2e6e 2a 2 and the mount of this filesystem fails. A subsequent manual second try to

Hi list This happened when running an iozone test over ceph, it was doing lots of random reads. I have no idea how to properly interpret this, I should find it out. Let me know if you need something else. Thanks! [69003.803272] ------------[ cut here ]------------ [69003.807987] kernel BUG at fs/btrfs/inode.c:6230! [69003.807987] invalid opcode: 0000 [#1] SMP [69003.807987] last sysfs file:

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

The system stopped responding to ssh but still responded to ping. The logs showed this error: (its long) Feb 4 00:08:08 server1 kernel: gdmgreeter: page allocation failure. order:0, mode:0x50 Feb 4 00:08:08 server1 kernel: [<c014f863>] __alloc_pages+0x28b/0x29d Feb 4 00:08:08 server1 kernel: [<c014b70f>] find_or_create_page+0x39/0x72 Feb 4 00:08:08 server1 kernel:

This version fixes three bugs in the 2nd patch of this series that caused kernel BUG when the system was under race. We weren't accounting with t_oustanding_credits correctly, and there were race conditions caused by the fact the I had overlooked the fact that __jbd2_log_wait_for_space() and jbd2_get_transaction() requires j_state_lock to be write locked. Theodore Ts'o (3): jbd2: Use