On 5.3.2016 06:34, Duncan wrote:
Chris Murphy posted on Fri, 04 Mar 2016 19:46:34 -0700 as excerpted:
On Fri, Mar 4, 2016 at 4:16 PM, Martin Mlynář wrote:
[Mount options line split/wrapped for followup]
rw,noatime,nodatasum,nodatacow,ssd,discard,space_cache,
enospc_debug,commit=900,subvo
On Sat, Mar 5, 2016 at 2:09 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> Roman Mamedov posted on Sat, 05 Mar 2016 03:49:10 +0500 as excerpted:
>
>> As you use the nodatacow mount option, this seems to be another case of
>> http://www.spinics.net/lists/linux-btrfs/msg51276.html
>> http://www.spinics.n
On 5.3.2016 11:46, Filipe Manana wrote:
On Sat, Mar 5, 2016 at 2:09 AM, Duncan <1i5t5.dun...@cox.net> wrote:
Roman Mamedov posted on Sat, 05 Mar 2016 03:49:10 +0500 as excerpted:
As you use the nodatacow mount option, this seems to be another case of
http://www.spinics.net/lists/linux-btrfs/
Hi Chris,
I apologize for not being able to deliver logs in the way you might
find them more helpful.
On Fri, Mar 04, 2016 at 12:08:10PM -0700, Chris Murphy wrote:
> On Fri, Mar 4, 2016 at 10:31 AM, Marc Haber
> wrote:
> > I have another btrfs on the same host that has no the no space left on
>
On Fri, Mar 04, 2016 at 07:09:39PM +0100, Holger Hoffstätte wrote:
> On 03/04/16 18:31, Marc Haber wrote:
> > I have another btrfs on the same host that has no the no space left on
> > device balance issue, but on another disk. On this btrfs, it seems
> > like a balance process is stuck, with a lot
Hi,
I have not seen this message coming back to the mailing list. Was it
again too long?
I have pastebinned the log at http://paste.debian.net/412118/
On Tue, Mar 01, 2016 at 08:51:32PM +, Duncan wrote:
> There has been something bothering me about this thread that I wasn't
> quite pinning
On Thu, Mar 03, 2016 at 02:28:36AM +0200, Dāvis Mosāns wrote:
> I've same issue, 4.4.3 kernel on Arch Linux
>
> $ sudo btrfs fi show /mnt/fs/
> Label: 'fs' uuid: a3c66d25-2c25-40e5-a827-5f7e5208e235
> Total devices 1 FS bytes used 396.94GiB
> devid1 size 435.76GiB used 435.76G
On 03/05/16 15:17, Marc Haber wrote:
>> Then try to balance in small increments.
>
> -dusage=5 and incrementing? Or what do you mean with "in small
> increments"?
Exactly, yes. Sorry for not being more clear.
FWIW I've been balancing a lot recently (both for stress testing and
cleaning up a few
On Sat, Mar 5, 2016 at 7:12 AM, Marc Haber wrote:
> What is the most helpful way to include logs?
Attach as a text file. If they're too big and get rejected, then it
depends. If I'm pretty sure it's a bug, I open a bug report on
bugzilla.kernel.org and attach there, then URL in list. If I'm not
On Sat, Mar 05, 2016 at 04:38:57PM +0100, Holger Hoffstätte wrote:
> On 03/05/16 15:17, Marc Haber wrote:
> >> Then try to balance in small increments.
> >
> > -dusage=5 and incrementing? Or what do you mean with "in small
> > increments"?
>
> Exactly, yes. Sorry for not being more clear.
So you
On 03/05/16 18:25, Marc Haber wrote:
> On Sat, Mar 05, 2016 at 04:38:57PM +0100, Holger Hoffstätte wrote:
>> On 03/05/16 15:17, Marc Haber wrote:
Then try to balance in small increments.
>>>
>>> -dusage=5 and incrementing? Or what do you mean with "in small
>>> increments"?
>>
>> Exactly, yes.
I'm not sure xfstests is the right fit, as it does not test a file
system, but rather block devices.
If people think it should go into xfstests we should at least not
add it to the default group, but just to a new bdev group.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs
I can't tell what this btrfs-balance script is doing because not every
btrfs balance command is in the log. It may be doing something not
advisable or suboptimal or unexpected that along with some other bug
is causing this to happen
Metadata,DUP: Size:107.00GiB, Used:2.11GiB
I'd try to use -musag
On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
> I can't tell what this btrfs-balance script is doing because not every
> btrfs balance command is in the log.
It is. I wrote it to produce reproducible logs.
[1/499]mh@fan:~$ cat btrfs-balance
#!/bin/bash
FS="/mnt/fanbtr"
showdf()
Looks fine,
Reviewed-by: Christoph Hellwig
--
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 http://vger.kernel.org/majordomo-info.html
Looks fine,
Reviewed-by: Christoph Hellwig
--
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 http://vger.kernel.org/majordomo-info.html
Looks fine,
Reviewed-by: Christoph Hellwig
--
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 http://vger.kernel.org/majordomo-info.html
Looks good,
Reviewed-by: Christoph Hellwig
--
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 http://vger.kernel.org/majordomo-info.html
Looks good,
Reviewed-by: Christoph Hellwig
--
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 http://vger.kernel.org/majordomo-info.html
Looks fine,
Reviewed-by: Christoph Hellwig
--
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 http://vger.kernel.org/majordomo-info.html
On Fri, Mar 04, 2016 at 04:37:43PM -0800, Darrick J. Wong wrote:
> Don't source common/xfs, since it doesn't (yet) exist.
Heh. Wonder how they ever worked before..
(they probably didn't, and I didn't notice as I never ran with rmapbt)
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this l
Looks fine,
Reviewed-by: Christoph Hellwig
--
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 http://vger.kernel.org/majordomo-info.html
Still fails for me:
--- tests/xfs/030.out 2016-03-03 07:55:58.556427678 +
+++ /root/xfstests/results//xfs/030.out.bad 2016-03-05 20:20:17.561433837
+
@@ -231,8 +231,6 @@
bad agbno AGBNO in agfl, agno 0
bad agbno AGBNO in agfl, agno 0
bad agbno AGBNO in agfl, agno 0
-bad agbno AGB
Fixes one warning for my config, but adds two new ones (see below).
Looks like we need to do some better feature detection.
--- tests/xfs/073.out 2016-03-03 07:55:58.556427678 +
+++ /root/xfstests/results//xfs/073.out.bad 2016-03-05 20:21:07.368100504
+
@@ -1,6 +1,4 @@
QA output c
Looks fine,
Reviewed-by: Christoph Hellwig
--
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 http://vger.kernel.org/majordomo-info.html
Signed-off-by: Christoph Hellwig
diff --git a/tests/xfs/209 b/tests/xfs/209
index cecd9c7..9bf1f12 100755
--- a/tests/xfs/209
+++ b/tests/xfs/209
@@ -73,7 +73,7 @@ echo "Check cowextsize settings"
seq 1 2 | while read nr; do
seq 1 4 | while read nnr; do
file="$testdir/dir
I have a btrfs filesystem spanning 3 drives. The metadata is using
raid1 (mirroring), but the data is using single, so no mirroring or
parity just spanning. For example:
mkfs.btrfs -m raid1 -d single /dev/sda /dev/sdb /dev/sdc
One of the drives, /dev/sdb, had a hardware failure before I could
When scanning extents, we didn't set num_bytes when visiting a tree
block extent. On the corrupted filesystem I was trying to fix, this
caused an extent to have its size guessed as zero, so we'd compute end
as start-1, which caused us to hit insert_state's BUG_ON(end
---
cmds-check.c |5 +++--
Holger Hoffstätte posted on Sat, 05 Mar 2016 16:38:57 +0100 as excerpted:
> On 03/05/16 15:17, Marc Haber wrote:
>>> Then try to balance in small increments.
>>
>> -dusage=5 and incrementing? Or what do you mean with "in small
>> increments"?
>
> Exactly, yes. Sorry for not being more clear.
>
Marc Haber posted on Sat, 05 Mar 2016 21:09:09 +0100 as excerpted:
> On Sat, Mar 05, 2016 at 12:34:09PM -0700, Chris Murphy wrote:
>> Something is happening with the usage of this file system that's out of
>> the ordinary. This is the first time I've seen such a large amount of
>> unused metadata
Justin Madru posted on Sat, 05 Mar 2016 12:32:31 -0800 as excerpted:
> I have a btrfs filesystem spanning 3 drives. The metadata is using raid1
> (mirroring), but the data is using single, so no mirroring or parity
> just spanning. For example:
>
> mkfs.btrfs -m raid1 -d single /dev/sda /dev/
31 matches
Mail list logo
