I was seeing root_list corruption on unmount during fs resize in 3.4-rc4; add
correct locking to address this.
Signed-off-by: Daniel J Blueman
---
fs/btrfs/relocation.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 017281d..5a105a0 1
On 04/24/2012 01:33 AM, Josef Bacik wrote:
> We can deadlock waiting for pages to end writeback because we are doing an
> allocation while hold a tree lock since the ordered extent stuff will
> require tree locks. A quick easy way to fix this is to end page writeback
> before we do our ordered io
On Mon, Apr 23, 2012 at 03:06:41PM -0400, Josef Bacik wrote:
> We already do the btrfs_wait_ordered_range which will do this for us, so
> just remove this call so we don't call it twice. Thanks,
>
> Signed-off-by: Josef Bacik
> ---
> fs/btrfs/file.c | 11 ++-
> 1 files changed, 6 inse
We already do the btrfs_wait_ordered_range which will do this for us, so
just remove this call so we don't call it twice. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/file.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
i
In btrfs_wait_ordered_range we have been calling filemap_fdata_write() twice
because compression does strange things and then waiting. Then we look up
ordered extents and if we find any we will always schedule_timeout(); once
and then loop back around and do it all again. We will even check to se
btrfs_start_delalloc_inodes will just walk the list of delalloc inodes and
start writing them out, but it doesn't splice the list or anything so as
long as somebody is doing work on the box you could end up in this section
_forever_. So just remove it, it's not needed anyway since sync will start
I know this question was asked, oh, a year ago, and the answer was
"No." But I'm wondering if anything's changed in the interim.
Specifically, shy of "dd", is there any way to back up the files and
metadata on a btrfs partition?
Thanks!
-Ken
--
To unsubscribe from this list: send the lin
These warnings are bogus since we will always have at least one page in an
eb, but to make the compiler happy just set ret = 0 in these two cases.
Thanks,
Btrfs: fix compile warnings in extent_io.c
These warnings are bogus since we will always have at least one page in an
eb, but to make the compi
When running compilebench I noticed we were spending some time looking up
acls on new inodes, which shouldn't be happening since there were no acls.
This is because when we init acls on the inode after creating them we don't
cache the fact there are no acls if there aren't any. Doing this adds a
l
We can deadlock waiting for pages to end writeback because we are doing an
allocation while hold a tree lock since the ordered extent stuff will
require tree locks. A quick easy way to fix this is to end page writeback
before we do our ordered io stuff, which works fine since we don't really
need
Hi,
I have here a Debian-based VM that was initially set up with a 2 GB
btrfs. As the installlation of a new kernel-header failed, I updated the
fs size to be 4, and later, 8 GB. However, the installation still runs
into an ENOSPC error. Still I can create many (empty) files, so I am
uncertai
I decided to run the test over the weekend. The good news is, that the
system is still running without performance degradation. But in the
meantime I've got over 5000 WARNINGs of this kind:
[330700.043557] btrfs: block rsv returned -28
[330700.043559] [ cut here ]
[330700.0
12 matches
Mail list logo
