[PATCH] Btrfs: fix memory leaks after transaction is aborted

From: Filipe Manana When a transaction is aborted, or its commit fails before writing the new superblock and calling btrfs_finish_extent_commit(), we leak reference counts on the block groups attached to the transaction's delete_bgs list, because btrfs_finish_extent_commit()

[PATCH] Btrfs: fix unprotected list move from unused_bgs to deleted_bgs list

From: Filipe Manana As of my previous change titled "Btrfs: fix scrub preventing unused block groups from being deleted", the following warning at extent-tree.c:btrfs_delete_unused_bgs() can be hit when we mount the a filesysten with "-o discard": 10263 void

Re: slowness when cp respectively send/receiving on top of dm-crypt

> I'm just copying (via send/receive) a large filesystem (~7TB) from on > HDD over to another. > The devices are both connected via USB3, and each of the btrfs is on > top of dm-crypt. As far as I can guess this is transfers between Seagate Archive 8TB SMR drives. For max 250GB in new/clean state

Re: How to detect / notify when a raid drive fails?

On Fri, 2015-11-27 at 17:16 +0800, Anand Jain wrote: >   I understand as a user, a full md/lvm set of features are important >   to begin operations using btrfs and we don't have it yet. I have to >   blame it on the priority list. What's would be especially nice from the admin side, would be

[PATCH] btrfs: fix misleading warning when space cache failed to load

When an inconsistent space cache is detected during loading we log a warning that users frequently mistake as instruction to invalidate the cache manually, even though this is not required. Fix the message to indicate that the cache will be rebuilt automatically. Signed-off-by: Holger Hoffstätte

Re: btrfs check help

My experience/interpretation of the 2 checks is that it is OK, see some more comments inserted below. Hopefully a developer of btrfs-progs can comment in more detail. > [root@3dcpc5 ~]# btrfs check --repair /dev/sdk > enabling repair mode > Checking filesystem on /dev/sdk > UUID:

slowness when cp respectively send/receiving on top of dm-crypt

Hey. Not sure if that's valuable input for the devs, but here's some vague real-world report about performance: I'm just copying (via send/receive) a large filesystem (~7TB) from on HDD over to another. The devices are both connected via USB3, and each of the btrfs is on top of dm-crypt. It's

Re: PAX: size overflow detected in function try_merge_map fs/btrfs/extent_map.c:238

On Fri, Nov 27, 2015 at 10:47 AM, Toralf Förster wrote: > Happened today few times in a row at a stable 64 bit Gentoo hardened system: > > > > Nov 27 10:23:09 t44 kernel: [41619.519921] PAX: size overflow detected in > function try_merge_map fs/btrfs/extent_map.c:238

Re: PAX: size overflow detected in function try_merge_map fs/btrfs/extent_map.c:238

On 11/27/2015 12:07 PM, Filipe Manana wrote: > Try the following (also pasted at > https://friendpaste.com/5O6o1cqWqJZDIKrH1YqG7y): Doesn't apply neither against the used 4.2.6 kernel nor aginst current git HEAD : t44 linux # patch -p1 --dry-run <

Re: PAX: size overflow detected in function try_merge_map fs/btrfs/extent_map.c:238

On Fri, Nov 27, 2015 at 11:20 AM, Toralf Förster wrote: > On 11/27/2015 12:07 PM, Filipe Manana wrote: >> Try the following (also pasted at >> https://friendpaste.com/5O6o1cqWqJZDIKrH1YqG7y): > > Doesn't apply neither against the used 4.2.6 kernel nor aginst current git >

Re: btrfs check help

> On Nov 26, 2015, at 10:03 PM, Vincent Olivier wrote: > >> >> On Nov 25, 2015, at 8:44 PM, Qu Wenruo wrote: >> >> >> >> Vincent Olivier wrote on 2015/11/25 11:51 -0500: >>> I should probably point out that there is 64GB of RAM on this machine and

Re: PAX: size overflow detected in function try_merge_map fs/btrfs/extent_map.c:238

On Fri, Nov 27, 2015 at 11:51 AM, Holger Hoffstätte wrote: > On 11/27/15 12:20, Toralf Förster wrote: >> On 11/27/2015 12:07 PM, Filipe Manana wrote: >>> Try the following (also pasted at >>> https://friendpaste.com/5O6o1cqWqJZDIKrH1YqG7y): >> >> Doesn't apply

Re: PAX: size overflow detected in function try_merge_map fs/btrfs/extent_map.c:238

On 11/27/15 12:20, Toralf Förster wrote: > On 11/27/2015 12:07 PM, Filipe Manana wrote: >> Try the following (also pasted at >> https://friendpaste.com/5O6o1cqWqJZDIKrH1YqG7y): > > Doesn't apply neither against the used 4.2.6 kernel nor aginst current git > HEAD : > > t44 linux # patch -p1

BTRFS: could not find root 8

After upgrading from systemd227 to 228 these messages began to show up during boot: [ 24.652118] BTRFS: could not find root 8 [ 24.664742] BTRFS: could not find root 8 Are they important? Regards, -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a

Re: btrfs check help

On Fri, Nov 27, 2015 at 4:25 AM, Vincent Olivier wrote: > > [root@3dcpc5 ~]# btrfs check --repair /dev/sdk > enabling repair mode > Checking filesystem on /dev/sdk > UUID: 6a742786-070d-4557-9e67-c73b84967bf5 > checking extents > Fixed 0 roots. > checking free space cache > cache

Re: BTRFS: could not find root 8

On Fri, Nov 27, 2015 at 10:33:29PM +0200, Imran Geriskovan wrote: > After upgrading from systemd227 to 228 > these messages began to show up during boot: > > [ 24.652118] BTRFS: could not find root 8 > [ 24.664742] BTRFS: could not find root 8 > > Are they important? That's the quota

Re: slowness when cp respectively send/receiving on top of dm-crypt

Hey. Send/receiving the master to the backup has finished just before... and now - not that I wouldn't trust btrfs, the hardware, etc. - I ran a complete diff --recursive --no-dereference over the snapshots on the two disks. The two btrfs are mounted ro (thus no write IO), there is not really

Re: btrfs: poor performance on deleting many large files

On Fri, 2015-11-27 at 03:38 +, Duncan wrote: > AFAIK, per-subvolume *atime mounts should already be working. Ah I see. :) Still, specifically for snapshots that's a bit unhandy, as one typically doesn't mount each of them... one rather mount e.g. the top level subvol and has a subdir

cannot move ro-snapshot directly but indirectly works

Hey. Not sure whether this is intended or not, but it feels at least somewhat strange: Consider I have a readonly snapshot (the only subvol here): /btrfs/snapshots/ro-snapshot now I want to move it to the dir: /btrfs/snapshots/foo/ i.e.  mv /btrfs/snapshots/ro-snapshot /btrfs/snapshots/foo/ but

Re: slowness when cp respectively send/receiving on top of dm-crypt

On Fri, 2015-11-27 at 20:00 +0100, Henk Slager wrote: > As far as I can guess this is transfers between Seagate Archive 8TB > SMR drives. Yes it is,... and I though about SMR being the reason at first, too, but: - As far as I understood SMR, it shouldn't kick in when I do what is mostly streaming

[GIT PULL] Btrfs

Hi Linus, I have a few fixes ready in my for-linus-4.4 branch. git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.4 This has Mark Fasheh's patches to fix quota accounting during subvol deletion, which we've been working on for a while now. The patch is pretty

Re: BTRFS: could not find root 8

On Fri, Nov 27, 2015 at 1:43 PM, Hugo Mills wrote: > On Fri, Nov 27, 2015 at 10:33:29PM +0200, Imran Geriskovan wrote: >> After upgrading from systemd227 to 228 >> these messages began to show up during boot: >> >> [ 24.652118] BTRFS: could not find root 8 >> [ 24.664742]

Re: [PATCH] Btrfs: fix unprotected list move from unused_bgs to deleted_bgs list

fdmanana posted on Fri, 27 Nov 2015 16:38:25 + as excerpted: > As of my previous change titled "Btrfs: fix scrub preventing unused > block groups from being deleted", the following warning at > extent-tree.c:btrfs_delete_unused_bgs() can be hit when we mount the a > filesysten with "-o

Re: BTRFS: could not find root 8

Chris Murphy posted on Fri, 27 Nov 2015 15:51:03 -0700 as excerpted: > On Fri, Nov 27, 2015 at 1:43 PM, Hugo Mills wrote: >> On Fri, Nov 27, 2015 at 10:33:29PM +0200, Imran Geriskovan wrote: >>> After upgrading from systemd227 to 228 these messages began to show up >>> during

Re: [PATCH] btrfs: fix misleading warning when space cache failed to load

Holger Hoffstätte posted on Fri, 27 Nov 2015 17:32:04 +0100 as excerpted: > When an inconsistent space cache is detected during loading we log a > warning that users frequently mistake as instruction to invalidate the > cache manually, even though this is not required. Fix the message to >

Re: btrfs: poor performance on deleting many large files

Christoph Anton Mitterer posted on Sat, 28 Nov 2015 04:57:05 +0100 as excerpted: > On Fri, 2015-11-27 at 03:38 +, Duncan wrote: >> AFAIK, per-subvolume *atime mounts should already be working. > Ah I see. :) > > Still, specifically for snapshots that's a bit unhandy, as one typically >

Re: implications of mixed mode

Lukas Pirl posted on Fri, 27 Nov 2015 23:30:05 +1300 as excerpted: > On 11/27/2015 04:11 PM, Duncan wrote as excerpted: >> My big hesitancy would be over that fact that very few will run or test >> mixed-mode at TB scale filesystem level [s]o you're relatively more >> likely to run into rarely

Re: PAX: size overflow detected in function try_merge_map fs/btrfs/extent_map.c:238

On 11/27/2015 12:53 PM, Filipe Manana wrote: > Indeed. > Try the following instead: http://paste.opensuse.org/view/raw/58412382 white-space damaged too, but the hint with --ingore- made it. Will see, if it helps now. But FWIW the mentioned spew happened the first time here AFAICT. -- Toralf,

[PATCH 3/4] btrfs: use smaller type for btrfs_path lowest_level

The level is 0..7, we can use smaller type. The size of btrfs_path is now 136 bytes from 144, which is +2 objects that fit into a 4k slab. Signed-off-by: David Sterba --- fs/btrfs/ctree.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/ctree.h

[PATCH 4/4] btrfs: use smaller type for btrfs_path locks

The values of btrfs_path::locks are 0 to 4, fit into a u8. Let's see: * overall size of btrfs_path drops down from 136 to 112 (-24 bytes), * better packing in a slab page +6 objects * the whole structure now fits to 2 cachelines * slight decrease in code size: textdata bss dec

[PATCH 2/4] btrfs: use smaller type for btrfs_path reada

The possible values for reada are all positive and bounded, we can later save some bytes by storing it in u8. Signed-off-by: David Sterba --- fs/btrfs/ctree.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index

[PATCH 0/4] Size reduction of btrfs_path

We can reduce size of btrfs_path by 32 bytes, which will lead to more objects packed into one slab page. Performance should not be worse and could even improve in some cases due to less cachelines used. Targetting 4.5. Thanks. Can be pulled from

[PATCH 1/4] btrfs: cleanup, use enum values for btrfs_path reada

Replace the integers by enums for better readability. The value 2 does not have any meaning since a717531942f488209dded30f6bc648167bcefa72 "Btrfs: do less aggressive btree readahead" (2009-01-22). Signed-off-by: David Sterba --- fs/btrfs/ctree.c | 9 -

Re: [PATCH] btrfs: use kbasename in btrfsic_mount

On Fri, Nov 27, 2015 at 10:11 AM, Rasmus Villemoes wrote: > This is more readable. Actually, Rasmus, a bit of offtopic here, but I would like to have your opinion for that clean up: http://www.spinics.net/lists/kernel/msg1411600.html -- With Best Regards, Andy

Re: How to detect / notify when a raid drive fails?

On 11/27/2015 01:30 PM, Duncan wrote: Ian Kelling posted on Thu, 26 Nov 2015 21:14:57 -0800 as excerpted: I'd like to run "mail" when a btrfs raid drive fails, but I don't know how to detect that a drive has failed. It don't see it in any docs. Otherwise I assume I would never know until

Re: [PATCH v2] btrfs: use kbasename in btrfsic_mount

On Fri, Nov 27, 2015 at 10:42 AM, Rasmus Villemoes wrote: > This is more readable. > > Signed-off-by: Rasmus Villemoes You missed David's tag. Anyway, also mine is here Reviewed-by Andy Shevchenko > --- > v2:

[PATCH] btrfs: use kbasename in btrfsic_mount

This is more readable. Signed-off-by: Rasmus Villemoes --- I think the following strlcpy may be somewhat fragile since obviously ds->name and p overlap. It certainly relies on strlcpy doing a forward copy, and since different architectures can have their own strlcpy,

Re: [PATCH] btrfs: use kbasename in btrfsic_mount

Hi Rasmus, [auto build test WARNING on: v4.4-rc2] [also build test WARNING on: next-20151127] url: https://github.com/0day-ci/linux/commits/Rasmus-Villemoes/btrfs-use-kbasename-in-btrfsic_mount/20151127-161249 config: i386-randconfig-s1-201547 (attached as .config) reproduce: # save

Re: [PATCH] btrfs: use kbasename in btrfsic_mount

On Fri, Nov 27, 2015 at 09:11:31AM +0100, Rasmus Villemoes wrote: > This is more readable. > > Signed-off-by: Rasmus Villemoes Reviewed-by: David Sterba -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a

Re: [PATCH] btrfs: use kbasename in btrfsic_mount

On Fri, Nov 27 2015, kbuild test robot <l...@intel.com> wrote: > Hi Rasmus, > > [auto build test WARNING on: v4.4-rc2] > [also build test WARNING on: next-20151127] > > url: > https://github.com/0day-ci/linux/commits/Rasmus-Villemoes/btrfs-use-kbasename-in-bt

[PATCH v2] btrfs: use kbasename in btrfsic_mount

This is more readable. Signed-off-by: Rasmus Villemoes --- v2: make p const char* (thanks 0day). Original comment: I think the following strlcpy may be somewhat fragile since obviously ds->name and p overlap. It certainly relies on strlcpy doing a forward copy, and

Re: implications of mixed mode

On 11/27/2015 04:11 PM, Duncan wrote as excerpted: > My big hesitancy would be over that fact that very few will run or test > mixed-mode at TB scale filesystem level, and where they do, it's likely > to be in ordered to work around the current (but set to soon be > eliminated) metadata-only

PAX: size overflow detected in function try_merge_map fs/btrfs/extent_map.c:238

Happened today few times in a row at a stable 64 bit Gentoo hardened system: Nov 27 10:23:09 t44 kernel: [41619.519921] PAX: size overflow detected in function try_merge_map fs/btrfs/extent_map.c:238 cicus.107_102 max, count: 13, decl: block_len; num: 0; context: extent_map; Nov 27 10:23:09