When btrfs_alloc_path() fails, btrfs_free_path() need not be called.
Therefore, it changes the branch ahead.
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -urNp linux-2.6.38-rc3/fs/btrfs/inode.c
linux-2.6.38-rc3.test/fs/btrfs/ino
When we're cleaning up the tree log we need to be able to remove free space from
the block group. The problem is if that free space spans bitmaps we would not
find the space since we're looking for too many bytes. So make sure the amount
of bytes we search for is limited to either the number of b
As this function is called in some error paths while not
removing the module, the __exit attribute prevents the kernel
image from linking when btrfs is compiled in statically.
Signed-off-by: Alexey Charkov
---
I am not completely sure whether this has already been reported,
but googling around d
Hi,
I'm looking at the code for btrfs_file_aio_write(). Specifically, the
following lines:
first_index = pos >> PAGE_CACHE_SHIFT;
last_index = (pos + iov_iter_count(&i)) >> PAGE_CACHE_SHIFT;
/*
* there are lots of better ways to do this, but this code
Hello Helmut,
On Wed, Jan 26, 2011 at 9:33 AM, Helmut Hullen wrote:
>
> Sorry - didn't solve my problem:
>
> -- last lines from "dmesg" ---
>
> bio too big device sdc (256 > 240)
> bio too big device sdc (256 > 240)
>
> [...] more than 800 such lines
>
> bio too big device
This has been resulting in a BUT_ON(ret) after btrfs_reserve_extent in
btrfs_cow_file_range. The reason is we don't actually calculate the bytes_super
for a block group until we go to cache it, which means that the space_info can
hand out reservations for space that it doesn't actually have, and w
On Di 1.Feb'11 at 16:25:11 -0600, cwillu wrote:
> On Tue, Feb 1, 2011 at 3:51 PM, Carlos R. Mafra wrote:
> >
> > I am running 2.6.37 plus the revert of bf9dc102e284 (which is related to
> > drm).
> >
> > My /home is on btrfs as well as a 1TB external USB hard-disk.
> >
> > I was compiling 2.6.38
