On 01/15/2013 02:35 PM, Bernd Schubert wrote:
Hrmm, that bug then seems to cause another bug. After the file system
went into RO, I simply umounted and mounted again and a few seconds
after that my entire system failed. Relevant logs are attached.
Further log attachment:
btrfsck
When you start btrfs scrub and point at one subvolume, what is scrubbed?
Just that subvolume or the entire volume?
Gene
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Tue, Jan 15, 2013 at 8:21 AM, Gene Czarcinski g...@czarc.net wrote:
When you start btrfs scrub and point at one subvolume, what is scrubbed?
Just that subvolume or the entire volume?
The entire volume.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a
Hi,
i had a similar scenario like Tomasz:
- Started with single 3TB Disk.
- Filled the 3TB Disk with a lot of files (more than 30 with 10-30GB)
- Added 2x 1,5TB Disks
- btrfs balance start dconvert=raid1 mconvert=raid1 $MOUNT
- # btrfs scrub start $MOUNT
- # btrfs scrub status $MOUNT
scrub
On Tue, Jan 15, 2013 at 10:47:57PM +0800, Liu Bo wrote:
We will crash on BUG_ON(ret == -EEXIST) when we do not resume the existing
balance but attempt to start a new one.
The steps can be:
1. start balance
2. pause balance
3. start balance
Signed-off-by: Liu Bo bo.li@oracle.com
---
The merge processing occurs during kmem_cache_create and you are setting
up the decoder field afterwards! Wont work.
In the thread I suggested providing the callback at destruction:
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg21130.html
I liked that it limits accesibility of
On Tue, Jan 15, 2013 at 8:49 AM, Marc MERLIN m...@merlins.org wrote:
On Mon, Jan 14, 2013 at 10:48:50PM -0800, David Brown wrote:
Why not make a snapshot of the root volume, and then delete the files
you want to move from the original root, and delete the rest of root
from the snapshot?
Are
On 14/01/13 16:34, Chris Mason wrote:
On Mon, Jan 14, 2013 at 09:32:25AM -0700, Tomasz Kusmierz wrote:
On 14/01/13 15:57, Chris Mason wrote:
On Mon, Jan 14, 2013 at 08:22:36AM -0700, Tomasz Kusmierz wrote:
On 14/01/13 14:59, Chris Mason wrote:
On Mon, Jan 14, 2013 at 04:09:47AM -0700, Tomasz
On Tue, Jan 15, 2013 at 04:32:10PM -0700, Tom Kusmierz wrote:
Chris all,
Sorry for not replying for that long but Chris old friend stress.sh
have proven that all my storage is affected with this bug and first
thing was to bring everything down before corruptions will spread any
further.
On Tue, Jan 15, 2013 at 04:30:52PM +, Christoph Lameter wrote:
On Mon, 14 Jan 2013, Liu Bo wrote:
This adds a leak decoder callback so that kmem_cache_destroy()
can use to generate debugging output for the allocated objects.
Interesting idea.
@@ -3787,6 +3789,9 @@ static int
On Tue, Jan 15, 2013 at 09:01:05AM -0800, Zach Brown wrote:
The merge processing occurs during kmem_cache_create and you are setting
up the decoder field afterwards! Wont work.
In the thread I suggested providing the callback at destruction:
On Tue, Jan 15, 2013 at 06:59:04PM +0200, Ilya Dryomov wrote:
On Tue, Jan 15, 2013 at 10:47:57PM +0800, Liu Bo wrote:
We will crash on BUG_ON(ret == -EEXIST) when we do not resume the existing
balance but attempt to start a new one.
The steps can be:
1. start balance
2. pause balance
This adds a leak decoder callback so that slab destruction
can use to generate debugging output for the allocated objects.
Callers like btrfs are using their own leak tracking which will
manage allocated objects in a list(or something else), this does
indeed the same thing as what slab does. So
On wed, 16 Jan 2013 11:03:13 +0800, Liu Bo wrote:
This adds a leak decoder callback so that slab destruction
can use to generate debugging output for the allocated objects.
Callers like btrfs are using their own leak tracking which will
manage allocated objects in a list(or something else),
14 matches
Mail list logo
