On 11/01/2011 06:55 PM, Chris Mason wrote:
> On Tue, Nov 01, 2011 at 05:22:20PM +0800, Liu Bo wrote:
>> Hi,
>>
>> On 11/01/2011 10:49 AM, Chris Mason wrote:
>>> Hi everyone,
>>>
>>> I've pushed out a new integration branch, but it is not for general use.
>>>
>>> I'm still going through and hammeri
On tue, 1 Nov 2011 12:04:40 -0400, Chris Mason wrote:
> On Tue, Nov 01, 2011 at 03:39:11PM +0800, Miao Xie wrote:
>> Any Comment?
>
> This is definitely interesting, in terms of trying to avoid btree
> fragmentation and improve the performance of the allocator.
>
> But I'm worried about what happ
On Tue, Nov 01, 2011 at 11:11:10AM +0100, David Sterba wrote:
> Hi,
>
> On Mon, Oct 31, 2011 at 10:49:57PM -0400, Chris Mason wrote:
> > I've pushed out a new integration branch, but it is not for general use.
>
> Thank you!
>
> xfstests/083 and 089 cause the following warnings. I've seen them b
On Tue, Nov 1, 2011 at 7:57 PM, Alexandre Oliva wrote:
> Hi, Gustavo,
>
> On Nov 1, 2011, Gustavo Sverzut Barbieri wrote:
>
>> btrfs csum failed ino 2957021 extent 85041815552 csum 667310679
>> wanted 0 mirror 0
>
>> Is there any way to recover it? :-S
>
> Did you try mounting without data ch
Hi, Gustavo,
On Nov 1, 2011, Gustavo Sverzut Barbieri wrote:
> btrfs csum failed ino 2957021 extent 85041815552 csum 667310679
> wanted 0 mirror 0
> Is there any way to recover it? :-S
Did you try mounting without data checksums?
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~l
Error checking block got moved mistakenly exposing us to a potential
segmentation fault.
Signed-off-by: Ilya Dryomov
---
mkfs.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/mkfs.c b/mkfs.c
index e3ced19..a6f6b1f 100644
--- a/mkfs.c
+++ b/mkfs.c
@@ -1328,7 +132
Currently mkfs in response to
mkfs.btrfs -d raid10 dev1 dev2
instead of telling "you can't do that" creates a SINGLE on two devices,
and only rebalance can transform it to raid0. Generally, it never warns
users about decisions it makes and it's not at all obvious which profile
it picks when.
Hallo, Ilya,
Du meintest am 01.11.11:
>> Mounting doesn't work immediately; most times I have to run the
>> "mount" command three times - strange.
> To be able to run mount only once you have to run 'btrfs dev scan' on
> startup (after each reboot or just before mounting).
That command has run,
On Tue, Nov 01, 2011 at 08:36:00PM +0100, Helmut Hullen wrote:
> Hallo,
>
> I'm just playing with "btrfs scrub".
>
> Kernel 3.1 (self made)
> btrfs integration-20111030 (Hugo Mills)
>
> I have a bundle of 3 2-TByte-disks (data raid0, metadata raid1).
>
> Since some (few) weeks one of the disks
Hallo,
I'm just playing with "btrfs scrub".
Kernel 3.1 (self made)
btrfs integration-20111030 (Hugo Mills)
I have a bundle of 3 2-TByte-disks (data raid0, metadata raid1).
Since some (few) weeks one of the disks makes errors (I've reported the
problems in this mailing list).
The bundle uses
Hello,
I'm using kernel 3.1.0 and I have both / and /home as btrfs. I used
suspend to ram quite often and never had a problem, but yesterday I've
suspended to get into a plane and when I resumed my /home was all
about input/output errors. Reboot did not help either. My root (/)
did not suffer any
I fixed a problem where we weren't reserving space for an orphan item when we
had to fallback to using the global reserve for an unlink, but I introduced
another problem. I was migrating the bytes from the transaction reserve to the
global reserve and then releasing from the global reserve in
btrf
On Tue, Nov 01, 2011 at 11:36:37AM +0100, David Sterba wrote:
> xfstests/214
>
> [ 3142.654774] [ cut here ]
> [ 3142.656017] kernel BUG at fs/btrfs/tree-log.c:3106!
> [ 3142.656017] invalid opcode: [#1] SMP
> [ 3142.656017] CPU 0
> [ 3142.656017] Modules linked in: lo
Hello,
I've just pulled btrfs-progs from the new git repo
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
However, when I come to make it fails like so:
gcc -Wp,-MMD,./.btrfsctl.o.d,-MT,btrfsctl.o -Wall -D_FILE_OFFSET_BITS=64
-D_FORTIFY_SOURCE=2 -g -Werror -Os -c btrfsctl.c
g
On Tue, Nov 01, 2011 at 06:56:50AM -0400, Chris Mason wrote:
> On Tue, Nov 01, 2011 at 11:36:37AM +0100, David Sterba wrote:
> > xfstests/214
> >
> > [ 3142.654774] [ cut here ]
> > [ 3142.656017] kernel BUG at fs/btrfs/tree-log.c:3106!
>
> What kind of hardware are you ru
On Tue, Nov 01, 2011 at 03:39:11PM +0800, Miao Xie wrote:
> Any Comment?
This is definitely interesting, in terms of trying to avoid btree
fragmentation and improve the performance of the allocator.
But I'm worried about what happens to performance as the FS fills up?
What kind of benchmarks have
On Tue, Nov 01, 2011 at 02:29:50PM +, em...@joachim-neu.de wrote:
>
> Hello,
>
> I'm taking a look at the B-tree level of btrfs. I have a dir item
> which is a symlink and I'm wondering where I can get the symlink's
> target from.
I'm not 100% certain about the btrfs implementation from m
On Tue, Nov 01, 2011 at 02:29:50PM +, em...@joachim-neu.de wrote:
> I'm taking a look at the B-tree level of btrfs. I have a dir item which
> is a symlink and I'm wondering where I can get the symlink's target
> from.
The symlink target is stored as inline data, inside the leaf, see
btrfs_sy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, Oct 27, 2011 at 08:32:09PM -0400, Ken D'Ambrosio wrote:
> root@ubuntu:/tmp/btrfs-progs# ./btrfs-zero-log /dev/sda1
> parent transid verify failed on 100695031808 wanted 217713 found 217732
> parent transid verify failed on 100695031808 wanted
Hello,
I'm taking a look at the B-tree level of btrfs. I have a dir item which
is a symlink and I'm wondering where I can get the symlink's target
from.
I hope anyone can tell me? Is there a bloody technical documentation of
btrfs somewhere out there that can answer me questions like this?
On Tue, Nov 1, 2011 at 3:36 AM, Stephane CHAZELAS
wrote:
> Hiya,
>
> trying to restore a FS from a backup (tgz) on a freshly made
> btrfs this morning, I got ENOSPCs after about 100MB out of 4GB
> have been extracted. strace indicates that the ENOSPC are upon
> the open(O_WRONLY).
>
> Restoring wi
the related source pointers of the warnings and crash (detailed below):
[ 1186.540073] WARNING: at fs/btrfs/extent-tree.c:5837
btrfs_alloc_free_block+0x337/0x350 [btrfs]()
[ 1186.541076] WARNING: at fs/btrfs/extent-tree.c:4617
__btrfs_free_extent+0x60d/0x6c0 [btrfs]()
[ 1186.541234] BUG: unable
On 23.08.2011 22:01, Ilya Dryomov wrote:
> Implement an ioctl for pausing restriper. This pauses the relocation,
> but restripe is still considered to be "in progress": restriper item is
> not deleted, other volume operations cannot be started, etc. If paused
> in the middle of profile changing o
On 01.11.2011 12:07, David Sterba wrote:
> On Tue, Nov 01, 2011 at 11:08:38AM +0100, Arne Jansen wrote:
>>> +/*
>>> + * Should be called with restripe_mutex held
>>> + */
>>> +int btrfs_restripe(struct restripe_control *rctl)
>>> +{
> ...
>>> + if (rctl->data.target & BTRFS_BLOCK_GROUP_DUP) {
>>>
On Tue, Nov 01, 2011 at 11:08:38AM +0100, Arne Jansen wrote:
> > +/*
> > + * Should be called with restripe_mutex held
> > + */
> > +int btrfs_restripe(struct restripe_control *rctl)
> > +{
...
> > + if (rctl->data.target & BTRFS_BLOCK_GROUP_DUP) {
> > + printk(KERN_ERR "btrfs: dup for
this time I'm not quite sure which xfstest triggered it, but there was
209 35s ... [11:20:19] [11:20:53] [failed, exit status 1] - output mismatch
(see 209.out.bad)
--- 209.out 2011-02-11 11:42:31.0 +0100
+++ 209.out.bad 2011-11-01 11:20:53.0 +0100
@@ -1,2 +1,2 @@
QA outp
On 23.08.2011 22:01, Ilya Dryomov wrote:
> On mount, if restripe item is found, resume restripe in a separate
> kernel thread.
>
> Try to be smart to continue roughly where previous balance (or convert)
> was interrupted. For chunk types that were being converted to some
> profile we turn on soft
On Tue, Nov 01, 2011 at 11:36:37AM +0100, David Sterba wrote:
> xfstests/214
>
> [ 3142.654774] [ cut here ]
> [ 3142.656017] kernel BUG at fs/btrfs/tree-log.c:3106!
What kind of hardware are you running this on? I'm passing 214 here.
-chris
--
To unsubscribe from this l
On Mon, Oct 31, 2011 at 07:33:21PM +0800, Wu Fengguang wrote:
> > //regression
> > 3) much increased cpu %user and %system for btrfs
>
> Sorry I find out that the CPU time regressions for btrfs are caused by
> some additional trace events enabled on btrfs (for debugging an
> unrelated btrfs hang b
On Tue, Nov 01, 2011 at 05:22:20PM +0800, Liu Bo wrote:
> Hi,
>
> On 11/01/2011 10:49 AM, Chris Mason wrote:
> > Hi everyone,
> >
> > I've pushed out a new integration branch, but it is not for general use.
> >
> > I'm still going through and hammering on the new logging code code to
> > make s
On Sat, Oct 29, 2011 at 04:39:44AM +0800, Wu Fengguang wrote:
> [restore CC list]
>
> > > I'm trying to understand where the performance gain comes from.
> > >
> > > I noticed that in all cases, before/after patchset, nr_vmscan_write are
> > > all zero.
> > >
> > > nr_vmscan_immediate_reclaim i
xfstests/214
[ 3142.654774] [ cut here ]
[ 3142.656017] kernel BUG at fs/btrfs/tree-log.c:3106!
[ 3142.656017] invalid opcode: [#1] SMP
[ 3142.656017] CPU 0
[ 3142.656017] Modules linked in: loop btrfs aoe
[ 3142.656017]
[ 3142.656017] Pid: 27328, comm: xfs_io Tainted:
On 23.08.2011 22:01, Ilya Dryomov wrote:
> Introduce a new btree objectid for storing restripe item. The reason is
> to be able to resume restriper after a crash with the same parameters.
> Restripe item has a very high objectid and goes into tree of tree roots.
>
> The key for the new item is as
On 23.08.2011 22:01, Ilya Dryomov wrote:
> Select chunks that are less than X percent full.
>
> Signed-off-by: Ilya Dryomov
> ---
> fs/btrfs/volumes.c | 33 +
> fs/btrfs/volumes.h |1 +
> 2 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/fs
Hi,
On Mon, Oct 31, 2011 at 10:49:57PM -0400, Chris Mason wrote:
> I've pushed out a new integration branch, but it is not for general use.
Thank you!
xfstests/083 and 089 cause the following warnings. I've seen them before when
testing josef/for-chris and josef/master branches (reported on irc)
On 23.08.2011 22:01, Ilya Dryomov wrote:
> Add basic restriper infrastructure: ioctl to start restripe, all
> restripe ioctl data structures, add data structure for tracking
> restriper's state to fs_info. Duplicate balancing code for restriper,
> btrfs_balance() will be removed when restriper is
Hi,
On 11/01/2011 10:49 AM, Chris Mason wrote:
> Hi everyone,
>
> I've pushed out a new integration branch, but it is not for general use.
>
> I'm still going through and hammering on the new logging code code to
> make sure it is properly backwards compatible with older kernels and
> that it h
Hiya,
trying to restore a FS from a backup (tgz) on a freshly made
btrfs this morning, I got ENOSPCs after about 100MB out of 4GB
have been extracted. strace indicates that the ENOSPC are upon
the open(O_WRONLY).
Restoring with:
mkfs.btrfs /dev/mapper/VG_USB-root
mount -o compress-force,ssd $_ /
On 23.08.2011 22:01, Ilya Dryomov wrote:
> Right now on-disk BTRFS_BLOCK_GROUP_* profile bits are used for
> avail_{data,metadata,system}_alloc_bits fields, which are there to tell
> us about available allocation profiles in the fs. When chunk is
> created, it's profile is OR'ed with respective av
Any Comment?
On Thu, 08 Sep 2011 16:18:09 +0800, Miao Xie wrote:
> This patch introduce free space cluster for each node in the b+tree. And
> we also simplify the fill method and the space allocation of the cluster:
> - Allocate free space cluster for each node
> - Allocate the free space extent (
40 matches
Mail list logo
