(2011/06/08 0:46), Chris Mason wrote:
> Excerpts from liubo's message of 2011-06-07 04:36:56 -0400:
>> On 06/07/2011 04:24 PM, Tsutomu Itoh wrote:
>>> (2011/06/07 15:17), Tsutomu Itoh wrote:
(2011/06/07 14:59), Tsutomu Itoh wrote:
> Hi liubo,
>
> (2011/06/07 14:31), liubo wrote:
>>
The size of struct btrfs_ioctl_fs_info_args is as big as 1KB, so
don't declare the variable on stack.
Signed-off-by: Li Zefan
---
fs/btrfs/ioctl.c | 23 ++-
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index ac37040..97
The WARN_ON() in start_transaction() was triggered while balancing.
The cause is btrfs_relocate_chunk() started a transaction and
then called iput() on the inode that stores free space cache,
and iput() called btrfs_start_transaction() again.
Reported-by: Tsutomu Itoh
Signed-off-by: Li Zefan
--
On 06/06/2011 09:39 PM, Miao Xie wrote:
> On fri, 03 Jun 2011 14:46:10 -0400, Josef Bacik wrote:
>> I got a lot of these when running stress.sh on my test box
>>
>> [ 9792.654889] [ cut here ]
>> [ 9792.654898] WARNING: at fs/btrfs/extent-tree.c:5681
>> btrfs_alloc_free_bloc
We have to do weird things when handling enospc in the transaction joining code.
Because we've already joined the transaction we cannot commit the transaction
within the reservation code since it will deadlock, so we have to return EAGAIN
and then make sure we don't retry too many times. Instead o
We keep having problems with early enospc, and that's because our method of
making space is inherently racy. The problem is we can have one guy trying to
make space for himself, and in the meantime people come in and steal his
reservation. In order to stop this we make a waitqueue and put anybody
Sergei accidently introduced a regression with
c4f675cd40d955d539180506c09515c90169b15b
The problem isn't his patch, it's that we are entirely too touchy to changes in
this area because the way we deal with pressure is racy in general. The other
problem is even though delalloc bytes are 0, we st
For some reason btrfs_update_reserved_bytes was only ever updating the
bytes_reserved counter of the space info if the space info was data. I assume
this is because the original enospc stuff used bytes_reserved to account for
space reserved for enospc accounting, but now that we're using bytes_may
We have been using space_info->bytes_reserved in the metadata case to cover our
reservations for ENOSPC. The problem with this is thats horribly wrong. We use
bytes_reserved to keep track of how many bytes the allocator has outstanding
that haven't actually been made into extents yet. So what ha
Me too. I've got a 9TB filesystem that I can't mount since rebooting
during a rebalance. I want to get the fs as repaired as possible, but
I am not in a hurry, and I have enough space at present to make a
duplicate and play with test versions of the repair.
--jeff
On Mon, Jun 6, 2011 at 9:41 AM
Excerpts from liubo's message of 2011-06-07 04:36:56 -0400:
> On 06/07/2011 04:24 PM, Tsutomu Itoh wrote:
> > (2011/06/07 15:17), Tsutomu Itoh wrote:
> >> (2011/06/07 14:59), Tsutomu Itoh wrote:
> >>> Hi liubo,
> >>>
> >>> (2011/06/07 14:31), liubo wrote:
> On 06/06/2011 04:33 PM, Tsutomu Itoh
On 06/06/2011 09:39 PM, Miao Xie wrote:
On fri, 03 Jun 2011 14:46:10 -0400, Josef Bacik wrote:
I got a lot of these when running stress.sh on my test box
[ 9792.654889] [ cut here ]
[ 9792.654898] WARNING: at fs/btrfs/extent-tree.c:5681
btrfs_alloc_free_block+0xca/0x27c
Reorder extent_buffer to remove 8 bytes of alignment padding on 64 bit
builds. This shrinks its size to 128 bytes allowing it to fit into one
fewer cache lines and allows more objects per slab in its kmem_cache.
slabinfo extent_buffer reports :-
before:-
Sizes (bytes) Slabs
-
On 06/07/2011 04:24 PM, Tsutomu Itoh wrote:
> (2011/06/07 15:17), Tsutomu Itoh wrote:
>> (2011/06/07 14:59), Tsutomu Itoh wrote:
>>> Hi liubo,
>>>
>>> (2011/06/07 14:31), liubo wrote:
On 06/06/2011 04:33 PM, Tsutomu Itoh wrote:
> Hi,
>
> I encountered following panic using 'btrfs-u
(2011/06/07 15:17), Tsutomu Itoh wrote:
> (2011/06/07 14:59), Tsutomu Itoh wrote:
>> Hi liubo,
>>
>> (2011/06/07 14:31), liubo wrote:
>>> On 06/06/2011 04:33 PM, Tsutomu Itoh wrote:
Hi,
I encountered following panic using 'btrfs-unstable + for-linus'
kernel.
I ran "btr
15 matches
Mail list logo
