search for: sync_filesystems

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

...es_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_fastpath+0x22/0x3a Apr 22 09:13:49 daisy kernel: [142561.721069] INFO: task hdparm:22246 blocked for more...

...2 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_fastpath+0x22/0x3a > Apr 22 09:13:49 daisy kernel: [142561.721069] INFO: task hdpar...

...nel: [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_fastpath+0x22/0x3a >> Apr 22 09:13:49 daisy kernel: [142561.7210...

...? [<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_fastpath+0x22/0x3a >>> Apr 22 09:13:49 daisy...

In commit ea455f8ab68338ba69f5d3362b342c115bea8e13, we move the dentry lock put process into ocfs2_wq. This is OK for most case, but as for umount, it lead to at least 2 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

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

On 17/12/13 04:42, Rusty Russell wrote: > Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >> 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

On 17/12/13 04:42, Rusty Russell wrote: > Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >> 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

On 19/12/13 01:19, Rusty Russell wrote: > Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >> On 17/12/13 04:42, Rusty Russell wrote: >>> Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >>>> Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th. >>>> >>>> When an active virtio block device is

On 19/12/13 01:19, Rusty Russell wrote: > Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >> On 17/12/13 04:42, Rusty Russell wrote: >>> Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >>>> Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th. >>>> >>>> When an active virtio block device is

I want to report a btrfs bug that happened this morning on kernel 3.2.1. I was copying a +5 GB file between two external usb harddisks, one formated with btrfs (the source) and the other with ext4 (the destination). In the meantime I decided to compile the 3.3-rc1 kernel with the output dir on the ext4 external harddisk. After some time I started to get many I/O errors coming from the ext4 drive

Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: > On 17/12/13 04:42, Rusty Russell wrote: >> Heinz Graalfs <graalfs at linux.vnet.ibm.com> writes: >>> 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

Hiya, Recently, a btrfs file system of mine started to behave very poorly with some btrfs kernel tasks taking 100% of CPU time. # btrfs fi show /dev/sdb Label: none uuid: b3ce8b16-970e-4ba8-b9d2-4c7de270d0f1 Total devices 3 FS bytes used 4.25TB devid 2 size 2.73TB used 1.52TB path /dev/sdc devid 1 size 2.70TB used 1.49TB path /dev/sda4 devid 3 size

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