Hello list,
while running the same workload on two machines (single xeon and a dual
xeon) both with 64GB RAM.
I need to run echo 3 >/proc/sys/vm/drop_caches every 15-30 minutes to
keep the speed as good as on the non numa system. I'm not sure whether
this is related to numa.
Is there any sysctl
Sean Greenslade posted on Wed, 12 Oct 2016 18:29:55 -0400 as excerpted:
> Hi, all. I have a question about a backup plan I have involving
> send/receive. As far as I can tell, there's no way to to resume a send
> that has been interrupted. In this case, my interruption comes from an
> overbearing
Hiroshi Honda posted on Thu, 13 Oct 2016 10:28:19 +0900 as excerpted:
> I am using Btrfs RAID5 with 10x4T disks.
> Around 2 weeks ago, one disk of it was taking long time when read and
> write.
> So, I tried replace the disk with new disk by replace command ( btrfs
> replace ... ).
> But, it faile
Mein lieber Freund,
Ich moechte mich erstmals gerne vorstellen. Mein Name ist Herr Ortega Navas
die persoenliche Investment Berater und Vermoegensverwalterin meines
verstorbenen Mandanten, der ihre familienname tragt. Er war als privater
Geschaeftsmann im internationalen Bereich taetig. Im Jah
At 10/13/2016 10:29 PM, David Sterba wrote:
On Fri, Oct 07, 2016 at 03:23:00PM +0800, Qu Wenruo wrote:
+for img in $(find . \( -iname '*.img' -o \
+ -iname '*.img.xz' -o\
+ -iname '*.raw' -o \
+ -iname '*.raw.xz'
At 10/14/2016 01:44 AM, Omar Sandoval wrote:
On Thu, Oct 13, 2016 at 05:22:26PM +0800, Qu Wenruo wrote:
Kernel clear_cache mount option will only rebuilt free space cache if
used space of that chunk has changed.
So it won't ensure any corrupted free space cache get cleared.
So add a new opti
At 10/14/2016 05:03 AM, Zygo Blaxell wrote:
On Thu, Oct 13, 2016 at 08:35:02AM +0800, Qu Wenruo wrote:
At 10/13/2016 01:19 AM, Zygo Blaxell wrote:
On Wed, Oct 12, 2016 at 01:48:58PM +0800, Qu Wenruo wrote:
True, but if we ignore parity, we'd find that, RAID5 is just RAID0.
Degraded RAID5 i
At 10/13/2016 10:15 PM, David Sterba wrote:
Hi,
patches merged to devel, thanks. I made a few minor adjustments, not
bothering you with them.
Thanks for all your work.
Now I can just rebase my scrub work to devel branch.
On Tue, Oct 11, 2016 at 10:44:42AM +0800, Qu Wenruo wrote:
Branch c
On Thu, Oct 13, 2016 at 05:18:46PM -0400, Chris Mason wrote:
> > > > WARNING: CPU: 1 PID: 21706 at fs/btrfs/transaction.c:489
> > start_transaction+0x40a/0x440 [btrfs]
> > > > CPU: 1 PID: 21706 Comm: trinity-c16 Not tainted 4.8.0-think+ #14
> > > > c900019076a8 b731ff3c 00
Hi, I'm using OpenSUSE on a btrfs volume spanning 2 disks (set as raid1
for both metadata and data), no separate /home partition.
The distro loves to create dozens of subvolumes for various things and
makes snapshots, see:
alby@openSUSE-xeon:~> sudo btrfs subvolume list /
ID 257 gen 394 top level
On 10/13/2016 02:16 PM, Dave Jones wrote:
On Wed, Oct 12, 2016 at 10:42:46AM -0400, Chris Mason wrote:
> On 10/12/2016 10:40 AM, Dave Jones wrote:
> > On Wed, Oct 12, 2016 at 09:47:17AM -0400, Dave Jones wrote:
> > > On Tue, Oct 11, 2016 at 11:54:09AM -0400, Chris Mason wrote:
> > > >
> >
On Thu, Oct 13, 2016 at 08:35:02AM +0800, Qu Wenruo wrote:
> At 10/13/2016 01:19 AM, Zygo Blaxell wrote:
> >On Wed, Oct 12, 2016 at 01:48:58PM +0800, Qu Wenruo wrote:
> >>True, but if we ignore parity, we'd find that, RAID5 is just RAID0.
> >
> >Degraded RAID5 is not RAID0. RAID5 has strict constr
On Wed, Oct 12, 2016 at 10:42:46AM -0400, Chris Mason wrote:
> On 10/12/2016 10:40 AM, Dave Jones wrote:
> > On Wed, Oct 12, 2016 at 09:47:17AM -0400, Dave Jones wrote:
> > > On Tue, Oct 11, 2016 at 11:54:09AM -0400, Chris Mason wrote:
> > > >
> > > >
> > > > On 10/11/2016 10:45 AM, Da
On Thu, Oct 13, 2016 at 05:22:26PM +0800, Qu Wenruo wrote:
> Kernel clear_cache mount option will only rebuilt free space cache if
> used space of that chunk has changed.
>
> So it won't ensure any corrupted free space cache get cleared.
>
> So add a new option "--clear-space-cache v1|v2" to btrf
This was reported when docker failed to build against
btrfs-progs v4.8.1.
It includes ioctl.h which now calls BUILD_ASSERT(), which
is defined in kerncompat.h, which was not included in the
ioctl.h header file.
Signed-off-by: Eric Sandeen
---
diff --git a/ioctl.h b/ioctl.h
index a7235c0..abea7e
On Thu, Oct 06, 2016 at 05:13:32PM +0800, Qu Wenruo wrote:
> For tree reloc tree whose level is >= 2, the root node's parent will
> point to itself.
> In this case it will make btrfsck overflow its stack and cause segfault.
>
> While for tree reloc tree, it doesn't affect qgroup and kernel can
> h
Hi,
1-4 applied, thanks.
--
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
Hi,
patches merged to devel, thanks. I made a few minor adjustments, not
bothering you with them.
On Tue, Oct 11, 2016 at 10:44:42AM +0800, Qu Wenruo wrote:
> Branch can be fetched from:
> https://github.com/adam900710/btrfs-progs/tree/convert_inode_flags
I can pull the branches from you, either
On Fri, Oct 07, 2016 at 03:23:00PM +0800, Qu Wenruo wrote:
> +for img in $(find . \( -iname '*.img' -o \
> + -iname '*.img.xz' -o\
> + -iname '*.raw' -o \
> + -iname '*.raw.xz' \) | sort)
> +do
> + image=$(extract_image $
On Thu, Oct 13, 2016 at 12:04 PM, robbieko wrote:
> From: Robbie Ko
>
> Patch for test btrfs incremental send.
>
> Robbie Ko (4):
> btrfs: add test for an incremental send don't skip overwrite ref for
> inode 256
> btrfs: add test for an incremental send add gen for is_waiting_for_rm
>
On Thu, Oct 13, 2016 at 12:04 PM, robbieko wrote:
> From: Robbie Ko
>
> Test that an incremental send operation does not skip overwrite ref
> for inode 256, it's always exist.
Tests should have a description that non-developers can understand
(like QA people for e.g.).
I doubt most QA people kno
In processing deleted subvolume, we would skip keys based on subvolume
drop key. The condition only checks the keys at same level. This is not
correct. Consider the following situation of one deleted subvolume.
This is a node of subvolume root:
node 13459456000 level 3 items 9 free 484 generation
The patchsets fixes 2 problems in checking deleted subvolume.
First, there are cases missing in checking drop_key, this add up the missing
cases,
so the skipping flow could work correctly.
Second, the drop key is only applied to subvolume tree. This should be applied
to the
corresponding reloca
If subvolume is deleted, we add drop_key into the corresponding
root item, so we know where to start processing the deleted subvolume.
However, we don't skip the keys prior to the drop_key in corresponding
relocation tree of the deleted subvolume. As a result, we might run
into block that is freed
From: Robbie Ko
Test that an incremental send operation does not skip overwrite ref
for inode 256, it's always exist.
This test exercises scenarios used to fail in btrfs and are fixed by
the following patches for the linux kernel:
"Btrfs: incremental send, fix don't skip inode 256 in overwrite_
From: Robbie Ko
There a some case for overwrite ref,
because when new gen is waiting, and old name conflict,
but old name has been deleted.
This test exercises scenarios used to fail in btrfs and are fixed by
the following patches for the linux kernel:
"Btrfs: incremental send, add gen check if
From: Robbie Ko
There a some case, the old gen directory can not have new
data to write, can not cause overwitre ref, except inode 256.
This test exercises scenarios used to fail in btrfs and are fixed by
the following patches for the linux kernel:
"Btrfs: incremental send, add gen check in did
From: Robbie Ko
Patch for test btrfs incremental send.
Robbie Ko (4):
btrfs: add test for an incremental send don't skip overwrite ref for
inode 256
btrfs: add test for an incremental send add gen for is_waiting_for_rm
when some corner case
btrfs: add test for an incremental send
From: Robbie Ko
There a one case for old_gen waiting_for_rm,
but new_gen use get_cur_path with the same inode.
This test exercises scenarios used to fail in btrfs and are fixed by
the following patches for the linux kernel:
"Btrfs: incremental send, add gen for is_waiting_for_rm when some corne
On 13/10/16 00:47, Sean Greenslade wrote:
> I may just end up doing that. Hugo's responce gave me some crazy ideas
> involving a custom build of split that waits for a command after each
> output file fills, which would of course require an equally weird build
> of cat that would stall the pipe ind
Since commit b02441999efcc6152b87cd58e7970bb7843f76cf, we don't wait all
ordered extents, but I run into some enospc errors when doing large file
create and delete tests, it's because shrink_delalloc() does not write
enough delalloc bytes and wait them finished:
From: Miao Xie
Date: Mon, 4
Kernel clear_cache mount option will only rebuilt free space cache if
used space of that chunk has changed.
So it won't ensure any corrupted free space cache get cleared.
So add a new option "--clear-space-cache v1|v2" to btrfsck, to
completely wipe out free space cache.
So kernel won't complain
Add test case to check the basic function of --clear-space-cache.
Signed-off-by: Qu Wenruo
---
tests/fsck-tests/024-clear-space-cache/test.sh | 55 ++
1 file changed, 55 insertions(+)
create mode 100755 tests/fsck-tests/024-clear-space-cache/test.sh
diff --git a/tests/f
On Thu, Oct 13, 2016 at 1:37 AM, Liu Bo wrote:
> On Wed, Oct 12, 2016 at 10:23:52PM +0100, Filipe Manana wrote:
>> On Tue, Sep 6, 2016 at 10:51 PM, Liu Bo wrote:
>> > Hi Filipe,
>> >
>> > On Mon, Sep 05, 2016 at 04:28:09PM +0100, Filipe Manana wrote:
>> >> On Fri, Sep 2, 2016 at 8:35 PM, Liu Bo
At 10/12/2016 10:55 PM, David Sterba wrote:
On Thu, Jul 07, 2016 at 10:11:59AM +0800, Qu Wenruo wrote:
Btrfs_read_block_groups() function is the most time consuming function
if the fs is large and filled with small extents.
For a btrfs filled with 100,000,000 16K sized files, mount the fs tak
Hi David,
Any updates?
If you're busy on these fix, I could fix these problem and send a new
version.
Thanks,
Qu
At 09/08/2016 05:56 PM, David Sterba wrote:
On Thu, Sep 08, 2016 at 11:42:29AM +0200, David Sterba wrote:
On Wed, Sep 07, 2016 at 08:29:34AM +0800, Qu Wenruo wrote:
@@ -1265,19
At 10/13/2016 01:26 AM, David Sterba wrote:
On Wed, Oct 12, 2016 at 10:01:27PM +0800, Qu Wenruo wrote:
On 10/12/2016 09:58 PM, Abhay Sachan wrote:
Hi,
I tried building latest btrfs progs on CentOS 6, "./configure" failed
with the error:
checking for FIEMAP_EXTENT_SHARED defined in linux/fi
37 matches
Mail list logo