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

I'm not convinced this is right. From your test case, the problem isn't because we have journaled metadata blocks (which is what bufs) counts, but because fsync() depends on data blocks also getting flushed out to disks. However, if we aren't closing the transaction because of fsync(), I don't think we need to do a barrier in the case of an external journal. So instead of effectively unconditionally setting t_flushed_data_blocks (since bufs is nearly always going to be non-zero), I think ...

https://bugzilla.kernel.org/show_bug.cgi?id=15576 --- Comment #1 from Theodore Tso <tytso@mit.edu> 2010-03-22 02:13:37 --- On Fri, Mar 19, 2010 at 01:05:23AM +0000, bugzilla-daemon@bugzilla.kernel.org This is an e2fsprogs bug. If you run e2fsck at this point, pass 5 errors will be reported, that exactly correspond with what you report the kernel ends up complaining about: Free blocks count wrong for group #12 (2, counted=0). Free blocks count wrong for group #13 (2, ...

Yes. BTW Would it be correct to update j_tail in jbd2_journal_commit_transaction() to something more recent if we have issued an io-barrier to j_fs_dev? This will helps to reduce journal_recovery time which may be really painful in some slow devices. I've take a look at async commit logic: fs/jbd2/commit.c void jbd2_journal_commit_transaction(journal_t *journal) { 725: /* Done it all: now write the commit record asynchronously. */ if (JBD2_HAS_INCOMPAT_FEATURE(journal, ...

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 ...

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 ...

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 ...

Please separate things like this into two separate patches; it makes them much easier to review. Thanks, - Ted --

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 #10 from Eric Sandeen <sandeen@redhat.com> 2010-03-22 20:26:22 --- ah so you've been incrementally resizing it and it oopses each time? hmmm -- 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=15579 Eric Sandeen <sandeen@redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sandeen@redhat.com --- Comment #4 from Eric Sandeen <sandeen@redhat.com> 2010-03-22 21:40:52 --- Just for what it's worth, I've had trouble reproducing this on another brand of SSD... something like this (don't ...

Here is the patch I mentioned today on the call. It avoids (or at least reduces) serious latency (10 minutes or more) on a large filesystem (8TB+) on the first write, if the filesystem is nearly full. The latency is entirely due to seeking to read the block bitmaps, so is considerably less serious on flex_bg formatted filesystems. A better long-term approach would be to store in the superblock the last group that had space to allocate a stripe-sized chunk and/or flag in the ...