Re: mount btrfs takes 30 minutes, btrfs check runs out of memory

At 07/15/2016 12:39 PM, John Ettedgui wrote: On Thu, Jul 14, 2016 at 8:56 PM Qu Wenruo > wrote: Sorry for the late reply. Oh it's all good, it's only a been a few days. [Slow mount] In fact we also reproduce the same

Re: [BUG] Btrfs scrub sometime recalculate wrong parity in raid5: take two

15.07.2016 00:20, Chris Mason пишет: > > > On 07/12/2016 05:50 PM, Goffredo Baroncelli wrote: >> Hi All, >> >> I developed a new btrfs command "btrfs insp phy"[1] to further >> investigate this bug [2]. Using "btrfs insp phy" I developed a script >> to trigger the bug. The bug is not always

Re: mount btrfs takes 30 minutes, btrfs check runs out of memory

Sorry for the late reply. [Slow mount] In fact we also reproduce the same problem, and found the problem. It's related to the size of extent tree. If the extent tree is large enough, mount needs to do quite a lot of IO to read out all block group items. And such read is random small read

Re: [PATCH] Btrfs-progs: fix btrfs-map-logical to only print extent mapping info

At 07/15/2016 09:40 AM, Liu Bo wrote: I have a valid btrfs image which contains, ... item 10 key (1103101952 BLOCK_GROUP_ITEM 1288372224) itemoff 15947 itemsize 24 block group used 655360 chunk_objectid 256 flags DATA|RAID5 item 11 key (1103364096 EXTENT_ITEM

[PATCH] Btrfs-progs: fix btrfs-map-logical to only print extent mapping info

I have a valid btrfs image which contains, ... item 10 key (1103101952 BLOCK_GROUP_ITEM 1288372224) itemoff 15947 itemsize 24 block group used 655360 chunk_objectid 256 flags DATA|RAID5 item 11 key (1103364096 EXTENT_ITEM 131072) itemoff 15894 itemsize 53

Re: New btrfs sub command: btrfs inspect physical-find

On Thu, Jul 14, 2016 at 04:05:00PM -0700, Liu Bo wrote: > On Tue, Jul 12, 2016 at 11:40:13PM +0200, Goffredo Baroncelli wrote: > > Hi All, > > > > the enclosed patch adds a new btrfs sub command: "btrfs inspect > > physical-find". The aim of this new command is to show the physical > >

Re: [PATCH 0/3] Btrfs: fix free space tree bitmaps+tests on big-endian systems

On 07/14/2016 07:31 PM, Omar Sandoval wrote: From: Omar Sandoval So it turns out that the free space tree bitmap handling has always been broken on big-endian systems. Totally my bad. Patch 1 fixes this. Technically, it's a disk format change for big-endian systems, but it

[PATCH 0/3] Btrfs: fix free space tree bitmaps+tests on big-endian systems

From: Omar Sandoval So it turns out that the free space tree bitmap handling has always been broken on big-endian systems. Totally my bad. Patch 1 fixes this. Technically, it's a disk format change for big-endian systems, but it never could have worked before, so I won't go

[PATCH 1/3] Btrfs: fix free space tree bitmaps on big-endian systems

From: Omar Sandoval In convert_free_space_to_{bitmaps,extents}(), we buffer the free space bitmaps in memory and copy them directly to/from the extent buffers with {read,write}_extent_buffer(). The extent buffer bitmap helpers use byte granularity, which is equivalent to a

[PATCH 3/3] Btrfs: expand free space tree sanity tests to catch endianness bug

From: Omar Sandoval The free space tree format conversion functions were broken on big-endian systems, but the sanity tests didn't catch it because all of the operations were aligned to multiple words. This was meant to catch any bugs in the extent buffer code's handling of high

[PATCH 2/3] Btrfs: fix extent buffer bitmap tests on big-endian systems

From: Omar Sandoval The in-memory bitmap code manipulates words and is therefore sensitive to endianness, while the extent buffer bitmap code addresses bytes and is byte-order agnostic. Because the byte addressing of the extent buffer bitmaps is equivalent to a little-endian

Re: New btrfs sub command: btrfs inspect physical-find

On Tue, Jul 12, 2016 at 11:40:13PM +0200, Goffredo Baroncelli wrote: > Hi All, > > the enclosed patch adds a new btrfs sub command: "btrfs inspect > physical-find". The aim of this new command is to show the physical placement > on the disk of a file. Currently it handles all the profiles

Re: New btrfs sub command: btrfs inspect physical-find

On 07/12/2016 05:40 PM, Goffredo Baroncelli wrote: Hi All, the enclosed patch adds a new btrfs sub command: "btrfs inspect physical-find". The aim of this new command is to show the physical placement on the disk of a file. Currently it handles all the profiles (single, dup, raid1/10/5/6).

Re: [BUG] Btrfs scrub sometime recalculate wrong parity in raid5: take two

On 07/12/2016 05:50 PM, Goffredo Baroncelli wrote: Hi All, I developed a new btrfs command "btrfs insp phy"[1] to further investigate this bug [2]. Using "btrfs insp phy" I developed a script to trigger the bug. The bug is not always triggered, but most of time yes. Basically the script

Re: FIDEDUPERANGE with src_length == 0

On Thu, Jul 14, 2016 at 02:12:58PM -0400, Chris Mason wrote: > > > On 07/14/2016 02:06 PM, Darrick J. Wong wrote: > > On Wed, Jul 13, 2016 at 03:19:38PM +0200, David Sterba wrote: > > > On Tue, Jul 12, 2016 at 10:26:43PM -0700, Darrick J. Wong wrote: > > > > On Mon, Jul 11, 2016 at 05:35:37PM

Re: FIDEDUPERANGE with src_length == 0

On 07/14/2016 02:06 PM, Darrick J. Wong wrote: On Wed, Jul 13, 2016 at 03:19:38PM +0200, David Sterba wrote: On Tue, Jul 12, 2016 at 10:26:43PM -0700, Darrick J. Wong wrote: On Mon, Jul 11, 2016 at 05:35:37PM -0700, Omar Sandoval wrote: Hey, Darrick, generic/182 is failing on Btrfs for me

Re: FIDEDUPERANGE with src_length == 0

On Wed, Jul 13, 2016 at 03:19:38PM +0200, David Sterba wrote: > On Tue, Jul 12, 2016 at 10:26:43PM -0700, Darrick J. Wong wrote: > > On Mon, Jul 11, 2016 at 05:35:37PM -0700, Omar Sandoval wrote: > > > Hey, Darrick, > > > > > > generic/182 is failing on Btrfs for me with the following output: > >

Re: [PATCH] btrfs: allocate exact page array size in extent_buffer

On 07/14/2016 08:29 AM, David Sterba wrote: The calculation of extent_buffer::pages size was done for 4k PAGE_SIZE, but this wastes 15 unused pointers on arches with large page size. Eg. on ppc64 this gives 15 * 8 = 120 bytes. Signed-off-by: David Sterba Reviewed-by: Chris

[PATCH] btrfs: allocate exact page array size in extent_buffer

The calculation of extent_buffer::pages size was done for 4k PAGE_SIZE, but this wastes 15 unused pointers on arches with large page size. Eg. on ppc64 this gives 15 * 8 = 120 bytes. Signed-off-by: David Sterba --- fs/btrfs/ctree.h | 6 -- fs/btrfs/extent_io.c | 2 ++

Re: btrfs replace performance with missing drive

Sébastien Luttringer posted on Thu, 14 Jul 2016 13:18:49 +0200 as excerpted: > I have a performance issue with «btrfs replace» with raid5 and a _missing_ > device. My btrfs rely on 6x4TB HDD and the operating system is an Archlinux. > > In a nutshell, I will need 23 to 46 days to replace on

Re: btrfs replace performance with missing drive

Pray that you have no issue with anything in the short term and that you don't lose power to the system while it is going on. I did exactly as you are now and ended up with a corrupted filesystem due to what you are seeing. DO NOT interrupt it, or you may have big problems with filesystem

btrfs replace performance with missing drive

Hello, I have a performance issue with «btrfs replace» with raid5 and a _missing_ device. My btrfs rely on 6x4TB HDD and the operating system is an Archlinux. In a nutshell, I will need 23 to 46 days to replace on missing disk. # btrfs fi sh /home Label: 'raptor.home'  uuid:

Re: btrfs on sparc64 results in kernel stack trace in 1 minute test

On Thu, Jul 14, 2016 at 11:08 AM, Anatoly Pugachev wrote: > Hi! > > I'm using git (describe, v4.7-rc7-16-gcf875cc) kernel, > with patch "fix extent buffer bitmap tests on big-endian systems", see > [1] (to be able to load/use btrfs module) > > and getting brtfs filesystem

btrfs on sparc64 results in kernel stack trace in 1 minute test

Hi! I'm using git (describe, v4.7-rc7-16-gcf875cc) kernel, with patch "fix extent buffer bitmap tests on big-endian systems", see [1] (to be able to load/use btrfs module) and getting brtfs filesystem going to read only mode as well getting kernel stack trace in 1 minute after started to copying