search for: sync_filesystem

....) Tested minimally (it builds and boots.) It makes ext3_journal_stop take an sb, not an inode, as its final parameter. It also sets sb->s_need_sync_fs, not sb->s_dirt, as setting s_dirt was only ever a workaround for the lack of a proper sync-fs mechanism. Btw, we clear s_need_sync_fs in sync_filesystems(). Don't we also need to do the same in fsync_super()? --Stephen

...ock_bh+0x1b/0x20 Apr 22 09:11:49 daisy kernel: [142441.721172]? [<ffffffff811f98d8>] sync_inodes_sb_ub+0xa8/0x1d0 Apr 22 09:11:49 daisy kernel: [142441.721176]? [<ffffffff8114fa6f>] ? filemap_fdatawait+0x2f/0x40 Apr 22 09:11:49 daisy kernel: [142441.721181]? [<ffffffff81200f85>] __sync_filesystem+0x95/0xa0 Apr 22 09:11:49 daisy kernel: [142441.721184]? [<ffffffff8120151d>] sync_filesystems+0x30d/0x350 Apr 22 09:11:49 daisy kernel: [142441.721188]? [<ffffffff812016e5>] sys_sync+0x155/0x1a0 Apr 22 09:11:49 daisy kernel: [142441.721192]? [<ffffffff81571424>] system_call_fastp...

...9:11:49 daisy kernel: [142441.721172]? [<ffffffff811f98d8>] > sync_inodes_sb_ub+0xa8/0x1d0 > Apr 22 09:11:49 daisy kernel: [142441.721176]? [<ffffffff8114fa6f>] ? > filemap_fdatawait+0x2f/0x40 > Apr 22 09:11:49 daisy kernel: [142441.721181]? [<ffffffff81200f85>] > __sync_filesystem+0x95/0xa0 > Apr 22 09:11:49 daisy kernel: [142441.721184]? [<ffffffff8120151d>] > sync_filesystems+0x30d/0x350 > Apr 22 09:11:49 daisy kernel: [142441.721188]? [<ffffffff812016e5>] > sys_sync+0x155/0x1a0 > Apr 22 09:11:49 daisy kernel: [142441.721192]? [<ffffffff815714...

...: [142441.721172]? [<ffffffff811f98d8>] >> sync_inodes_sb_ub+0xa8/0x1d0 >> Apr 22 09:11:49 daisy kernel: [142441.721176]? [<ffffffff8114fa6f>] ? >> filemap_fdatawait+0x2f/0x40 >> Apr 22 09:11:49 daisy kernel: [142441.721181]? [<ffffffff81200f85>] >> __sync_filesystem+0x95/0xa0 >> Apr 22 09:11:49 daisy kernel: [142441.721184]? [<ffffffff8120151d>] >> sync_filesystems+0x30d/0x350 >> Apr 22 09:11:49 daisy kernel: [142441.721188]? [<ffffffff812016e5>] >> sys_sync+0x155/0x1a0 >> Apr 22 09:11:49 daisy kernel: [142441.721192]?...

...<ffffffff811f98d8>] >>> sync_inodes_sb_ub+0xa8/0x1d0 >>> Apr 22 09:11:49 daisy kernel: [142441.721176]? [<ffffffff8114fa6f>] ? >>> filemap_fdatawait+0x2f/0x40 >>> Apr 22 09:11:49 daisy kernel: [142441.721181]? [<ffffffff81200f85>] >>> __sync_filesystem+0x95/0xa0 >>> Apr 22 09:11:49 daisy kernel: [142441.721184]? [<ffffffff8120151d>] >>> sync_filesystems+0x30d/0x350 >>> Apr 22 09:11:49 daisy kernel: [142441.721188]? [<ffffffff812016e5>] >>> sys_sync+0x155/0x1a0 >>> Apr 22 09:11:49 daisy kern...

...bugs. See http://oss.oracle.com/bugzilla/show_bug.cgi?id=1133 and http://oss.oracle.com/bugzilla/show_bug.cgi?id=1135. And it happens easily if we have opened a lot of inodes. For 1135, the reason is that during umount will call generic_shutdown_super and it will do: 1. shrink_dcache_for_umount 2. sync_filesystem. 3. invalidate_inodes. In shrink_dcache_for_umount, we will drop the dentry, and queue ocfs2_wq for dentry lock put. While in invalidate_inodes we will call invalidate_list which will iterate all the inodes for the sb. The bad thing is that in this function it will call cond_resched_lock(&inod...

The reason the deadlock is that: Task Btrfs-cleaner umount() down_write(&s->s_umount) sync_filesystem() do auto-defragment and produce lots of dirty pages close_ctree() wait for the end of btrfs-cleaner start_transaction reserve space shrink_delalloc() writeback_inodes_sb_nr_if_idle() down_read(&sb->s_umount) So, the deadlock ha...

...rter+0x6/0xc 2 locks held by kjournald/1984: ... and end up in hang situations ... PID: 13 TASK: 1e3f8000 CPU: 0 COMMAND: "kworker/u128:1" #0 [1e2033e0] __schedule at 695ff2 #1 [1e203530] log_wait_commit at 3a28a6 #2 [1e2035a0] ext3_sync_fs at 328dea #3 [1e2035d8] sync_filesystem at 2c785c #4 [1e203600] fsync_bdev at 2d4650 #5 [1e203628] invalidate_partition at 3f80c8 #6 [1e203650] del_gendisk at 3f8f5c #7 [1e2036c8] virtblk_remove at 45e60e #8 [1e203700] virtio_dev_remove at 42d72e #9 [1e203738] __device_release_driver at 44f0b0 #10 [1e203760] device_release_dr...

...rter+0x6/0xc 2 locks held by kjournald/1984: ... and end up in hang situations ... PID: 13 TASK: 1e3f8000 CPU: 0 COMMAND: "kworker/u128:1" #0 [1e2033e0] __schedule at 695ff2 #1 [1e203530] log_wait_commit at 3a28a6 #2 [1e2035a0] ext3_sync_fs at 328dea #3 [1e2035d8] sync_filesystem at 2c785c #4 [1e203600] fsync_bdev at 2d4650 #5 [1e203628] invalidate_partition at 3f80c8 #6 [1e203650] del_gendisk at 3f8f5c #7 [1e2036c8] virtblk_remove at 45e60e #8 [1e203700] virtio_dev_remove at 42d72e #9 [1e203738] __device_release_driver at 44f0b0 #10 [1e203760] device_release_dr...

...up in hang situations ... >> >> PID: 13 TASK: 1e3f8000 CPU: 0 COMMAND: "kworker/u128:1" >> #0 [1e2033e0] __schedule at 695ff2 >> #1 [1e203530] log_wait_commit at 3a28a6 >> #2 [1e2035a0] ext3_sync_fs at 328dea >> #3 [1e2035d8] sync_filesystem at 2c785c >> #4 [1e203600] fsync_bdev at 2d4650 >> #5 [1e203628] invalidate_partition at 3f80c8 >> #6 [1e203650] del_gendisk at 3f8f5c >> #7 [1e2036c8] virtblk_remove at 45e60e >> #8 [1e203700] virtio_dev_remove at 42d72e >> #9 [1e203738] __devi...

...up in hang situations ... >> >> PID: 13 TASK: 1e3f8000 CPU: 0 COMMAND: "kworker/u128:1" >> #0 [1e2033e0] __schedule at 695ff2 >> #1 [1e203530] log_wait_commit at 3a28a6 >> #2 [1e2035a0] ext3_sync_fs at 328dea >> #3 [1e2035d8] sync_filesystem at 2c785c >> #4 [1e203600] fsync_bdev at 2d4650 >> #5 [1e203628] invalidate_partition at 3f80c8 >> #6 [1e203650] del_gendisk at 3f8f5c >> #7 [1e2036c8] virtblk_remove at 45e60e >> #8 [1e203700] virtio_dev_remove at 42d72e >> #9 [1e203738] __devi...

...469e>] write_ctree_super+0xe/0x10 [<ffffffff811b9778>] btrfs_commit_transaction+0x6a8/0x870 [<ffffffff811b8a8a>] ? join_transaction+0x24a/0x280 [<ffffffff810611f0>] ? wake_up_bit+0x40/0x40 [<ffffffff81195a57>] btrfs_sync_fs+0x47/0x70 [<ffffffff811029be>] __sync_filesystem+0x5e/0x90 [<ffffffff81102a53>] sync_filesystem+0x43/0x60 [<ffffffff810dc226>] generic_shutdown_super+0x36/0xe0 [<ffffffff810dc361>] kill_anon_super+0x11/0x20 [<ffffffff810dc715>] deactivate_locked_super+0x45/0x80 [<ffffffff810dd115>] deactivate_super+0x45/0x6...

.../1984: > > ... and end up in hang situations ... > > PID: 13 TASK: 1e3f8000 CPU: 0 COMMAND: "kworker/u128:1" > #0 [1e2033e0] __schedule at 695ff2 > #1 [1e203530] log_wait_commit at 3a28a6 > #2 [1e2035a0] ext3_sync_fs at 328dea > #3 [1e2035d8] sync_filesystem at 2c785c > #4 [1e203600] fsync_bdev at 2d4650 > #5 [1e203628] invalidate_partition at 3f80c8 > #6 [1e203650] del_gendisk at 3f8f5c > #7 [1e2036c8] virtblk_remove at 45e60e > #8 [1e203700] virtio_dev_remove at 42d72e > #9 [1e203738] __device_release_driver at 44f0b0 &g...

...lock+0xe/0x10 [515954.295050] [<ffffffffa02f7b07>] ? join_transaction.clone.23+0x1ca/0x200 [btrfs] [515954.295050] [<ffffffff81068ffb>] ? wake_up_bit+0x2a/0x2a [515954.295050] [<ffffffffa02dc45b>] ? btrfs_sync_fs+0x9f/0xa7 [btrfs] [515954.295050] [<ffffffff81135ba8>] ? __sync_filesystem+0x66/0x7a [515954.295050] [<ffffffff81135c20>] ? sync_filesystem+0x4c/0x50 [515954.295050] [<ffffffff811151d8>] ? generic_shutdown_super+0x38/0xf6 [515954.295050] [<ffffffff81115316>] ? kill_anon_super+0x16/0x50 [515954.295050] [<ffffffff81115540>] ? deactivate_locked_su...

This reverts commit 5500cdbe14d7435e04f66ff3cfb8ecd8b8e44ebf. We had numerous reports of premature ENOSPC that were bisected to this patch. Reverting will not break things but a warning in ''use_block_rsv'' may show up in the syslog. There''s no alternative fix in sight and the ENOSPC problem affects all 3.3 btrfs users during normal filesystem use. CC:

Currently the fs sync function (super.c:btrfs_sync_fs()) doesn''t wait for delayed work to finish before returning success to the caller. This change fixes this, ensuring that there''s no data loss if a power failure happens right after fs sync returns success to the caller and before the next commit happens. Steps to reproduce the data loss issue: $ mkfs.btrfs -f /dev/sdb3 $

Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th. When an active virtio block device is hot-unplugged from a KVM guest, affected guest user applications are not aware of any errors that occur due to the lost device. This patch-set adds code to avoid further request queueing when a lost block device is detected, resulting in appropriate error info. Additionally a potential

Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th. When an active virtio block device is hot-unplugged from a KVM guest, affected guest user applications are not aware of any errors that occur due to the lost device. This patch-set adds code to avoid further request queueing when a lost block device is detected, resulting in appropriate error info. Additionally a potential