Displaying 9 results from an estimated 9 matches for "filemap_flush".
2013 Oct 28
0
[PATCH] Btrfs: make sure the delalloc workers actually flush compressed writes
...delalloc_work(struct btrfs_work *work)
{
struct btrfs_delalloc_work *delalloc_work;
+ struct inode *inode;
delalloc_work = container_of(work, struct btrfs_delalloc_work,
work);
- if (delalloc_work->wait)
- btrfs_wait_ordered_range(delalloc_work->inode, 0, (u64)-1);
- else
- filemap_flush(delalloc_work->inode->i_mapping);
+ inode = delalloc_work->inode;
+ if (delalloc_work->wait) {
+ btrfs_wait_ordered_range(inode, 0, (u64)-1);
+ } else {
+ filemap_flush(inode->i_mapping);
+ if (test_bit(BTRFS_INODE_HAS_ASYNC_EXTENT,
+ &BTRFS_I(inode)->runtime_flags))...
2013 Jan 21
1
btrfs_start_delalloc_inodes livelocks when creating snapshot under IO
...o, I tested the behavior before your commit
8ccf6f19b67f7e0921063cc309f4672a6afcb528 "Btrfs: make delalloc inodes
be flushed by multi-task", on kernel 3.6. I see same issue there as
well, but OOM doesn''t happen, because before your change
btrfs_start_delalloc_inodes() was calling filemap_flush() directly.
But I see still that btrfs_start_delalloc_inodes() handles same inode
more than once, and in some cases never returns in 15 minutes or more,
delaying all other transactions. And snapshot creation gets stuck for
all this time.
(The stack I see on kernel 3.6 is like this:
[<ffffffff81...
2010 Mar 15
1
[PATCH 1/2] Btrfs: remove bad fsync transaction check
This check for a user transaction is a bogus: fsync() with an open user
transaction is verboten. If the caller is the same process who started
a user transaction, and this is a different file, we will deadlock. If
it''s the same file, this check means we won''t deadlock, but the
transaction will be prematurely closed out.
Any user transaction ioctl users should be careful to
2010 Nov 18
9
Interesting problem with write data.
Hi,
Recently, I made a btrfs to use. And I met slowness problem. Trying
to diag it. I found this:
1. dd if=/dev/zero of=test count=1024 bs=1MB
This is fast, at about 25MB/s, and reasonable iowait.
2. dd if=/dev/zero of=test count=1 bs=1GB
This is pretty slow, at about 1.5MB/s, and 90%+ iowait, constantly.
May I know why it works like this? Thanks.
--
To unsubscribe from this list: send the
2005 Jan 04
0
[PATCH] BUG on error handlings in Ext3 under I/O failure condition
...,7 @@
invalidate_inode_pages(inode->i_mapping);
}
extern void invalidate_inode_pages2(struct address_space *mapping);
-extern void write_inode_now(struct inode *, int);
+extern int write_inode_now(struct inode *, int);
extern int filemap_fdatawrite(struct address_space *);
extern int filemap_flush(struct address_space *);
extern int filemap_fdatawait(struct address_space *);
diff -Nru linux-2.4.29-pre3-bk2/fs/ext3/fsync.c
linux-2.4.29-pre3-bk2_fix/fs/ext3/fsync.c
--- linux-2.4.29-pre3-bk2/fs/ext3/fsync.c 2002-11-29 08:53:15.000000000 +0900
+++ linux-2.4.29-pre3-bk2_fix/fs/ext3/fsync...
2012 Aug 24
4
[PATCH] Btrfs: pass lockdep rwsem metadata to async commit transaction
The freeze rwsem is taken by sb_start_intwrite() and dropped during the
commit_ or end_transaction(). In the async case, that happens in a worker
thread. Tell lockdep the calling thread is releasing ownership of the
rwsem and the async thread is picking it up.
Josef and I worked out a more complicated solution that made the async
commit thread join and potentially get a later transaction, but
2010 Apr 19
0
[PATCH 08/12] Btrfs: Introduce global metadata reservation
...delayed allocation */
u64 disk_used; /* total bytes used on disk */
int full; /* indicates that we cannot allocate any more
chunks for this space */
int force_alloc; /* set if we need to force a chunk alloc for
this space */
- int force_delalloc; /* make people start doing filemap_flush until
- we''re under a threshold */
struct list_head list;
diff -urp 8/fs/btrfs/disk-io.c 9/fs/btrfs/disk-io.c
--- 8/fs/btrfs/disk-io.c 2010-04-18 10:24:51.286697000 +0800
+++ 9/fs/btrfs/disk-io.c 2010-04-18 10:47:31.056726210 +0800
@@ -1472,10 +1472,6 @@ static int cleaner_kthr...
2009 Aug 24
0
[PATCH] Btrfs: proper metadata -ENOSPC handling
...* we''re using rename to replace one file with another.
* and the replacement file is large. Start IO on it now so
@@ -4811,7 +4876,14 @@ static int btrfs_rename(struct inode *old_dir, struct dentry *old_dentry,
old_inode->i_size > BTRFS_ORDERED_OPERATIONS_FLUSH_LIMIT)
filemap_flush(old_inode->i_mapping);
- trans = btrfs_start_transaction(root, 1);
+ /*
+ * 2 items for dir items
+ * 1 item for orphan entry
+ * 1 item for ref
+ */
+ trans = btrfs_start_transaction(root, 4);
+ if (IS_ERR(trans))
+ return PTR_ERR(trans);
/*
* make sure the inode gets flushed if i...
2012 Apr 20
44
Ceph on btrfs 3.4rc
After running ceph on XFS for some time, I decided to try btrfs again.
Performance with the current "for-linux-min" branch and big metadata
is much better. The only problem (?) I''m still seeing is a warning
that seems to occur from time to time:
[87703.784552] ------------[ cut here ]------------
[87703.789759] WARNING: at fs/btrfs/inode.c:2103