We could potentially put the dirty flag in the inode instead, and set it write_prepare() and writepages() code paths. I'm not entirely sure I've added this to the ext4 patch queue, and I will ignore your earlier version of the patch. - Ted --

This means that we will end up with two io-barriers in a row for external journal case: ext4_sync_file() ->jbd2_log_start_commit() ->blkdev_issue_flush(j_fs_dev) /* seems following flush is mandatory to guarantee the metadata * consistency */ ->blkdev_issue_flush(j_fs_dev) may be it will be better to pass some sort of barrier flag to jbd2_log_start_commit() this function mark journal->j_commit_request with ->t_flushed_data_blocks = 1, so io-carrier will be issued even if ...

Just to be clear, since I realized I wrote fsync() when I should have written fs/ext4/fsync.c, my proposal was to put this check in Um, maybe. We are already calling __jbd2_journal_clean_checkpoint_list(), and the barrier operation *is* expensive. On the other hand, updating the journal superblock on every sync is another seek that would have to made before the barrier operation, and I'm a bit concerned that this seek would be noticeable. If it is noticeable, is it worth it to optimize ...

Thanks for the patch. This is what I've checked in, which also simplifies the error handling a bit and makes the code a bit easier to follow. - Ted ext4: fix memory leaks in error path handling of ext4_ext_zeroout() From: jing zhang <zj.barak@gmail.com> When EIO occurs after bio is submitted, there is no memory free operation for bio, which results in memory leakage. And there is also no check against bio_alloc() for bio. Acked-by: Dave Kleikamp ...

It would be better if this could be done by making ext4_mb_release() more flexible, and then calling ext4_mb_release() if there is an error setting up the data structures in ext4_mb_init(). - Ted --

https://bugzilla.kernel.org/show_bug.cgi?id=15576 --- Comment #2 from xpenev@gmail.com 2010-03-22 05:34:37 --- You guys are awesome :) This let's me get back on my way. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. --

From: Jing Zhang <zj.barak@gmail.com> Date: Mon Mar 22 22:20:38 2010 1, In one of the hot functions in mballoc.c, unnecessary operation on struct ext4_group_desc *desc; is removed. 2, Unlike spin_lock() and spin_unlock(), ext4_mb_load_buddy() is companied by ext4_mb_release_desc. And it is hard, at least for me, to get sure that ext4_mb_release_desc has little to do with struct ext4_group_desc, and for those readers as well, whose native language is not English. It seems ...

Hi, We have a BH_Delay flag for this already. OK, probably you need a temporary flag which you can clear in ext4_da_write_begin. I'd find counting number of BH_Delay buffers before and after block_write_begin Probably you are hitting some lock inversion problem. I suggest you compile the kernel with lockdep enabled (in Kernel hacking -> Lock debugging -> Prove lock correctness or something like that) and see whether it issues some warnings. If not, you can get backtraces of the locked up ...

https://bugzilla.kernel.org/show_bug.cgi?id=13549 --- Comment #7 from Alessandro Polverini <alex@nibbles.it> 2010-03-22 17:00:22 --- Hello Eric, here is the output of dumpe2fs (the file system was mounted when running it). Please note that now the FS has been expanded, but the operation has been done (like the other times) offline (unmounted). The kernel hangs when trying to do it online (mounted). dumpe2fs 1.41.3 (12-Oct-2008) Filesystem volume name: <none> Last mounted on: ...

https://bugzilla.kernel.org/show_bug.cgi?id=13549 --- Comment #9 from Alessandro Polverini <alex@nibbles.it> 2010-03-22 20:16:20 --- The problem is reproducible at will, this is not the first time I resized the partition and everytime there was a kernel oops. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. --

https://bugzilla.kernel.org/show_bug.cgi?id=13549 --- Comment #11 from Alessandro Polverini <alex@nibbles.it> 2010-03-22 20:41:25 --- Yes, a kernel oops each time. And each time I made a new test I upgraded the kernel, so I verified the problem on all versions from 2.6.29 to 2.6.32, if I remember well. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. --

https://bugzilla.kernel.org/show_bug.cgi?id=13549 --- Comment #12 from Eric Sandeen <sandeen@redhat.com> 2010-03-22 21:51:35 --- I'm afraid I've not been able to reproduce it: create a sparse loopback filesystem: [root@inode test]# touch fsfile [root@inode test]# truncate --size 1020054732800 fsfile [root@inode test]# ls -lh fsfile -rw-r--r--. 1 root root 950G Mar 22 16:28 fsfile [root@inode test]# mkfs.ext4 fsfile mke2fs 1.41.10 (10-Feb-2009) <at this point I checked that ...