Re: [PATCH v2] Btrfs: fix memory leak of block group cache

On 07/21/2016 03:03 PM, Liu Bo wrote: On Thu, Jul 21, 2016 at 11:32:26AM -0400, Chris Mason wrote: On 07/20/2016 08:44 PM, Liu Bo wrote: While processing delayed refs, we may update block group's statistics and attach it to cur_trans->dirty_bgs, and later writing dirty block gro

Re: [PATCH v2] Btrfs: fix memory leak of block group cache

On 07/20/2016 08:44 PM, Liu Bo wrote: While processing delayed refs, we may update block group's statistics and attach it to cur_trans->dirty_bgs, and later writing dirty block groups will process the list, which happens during btrfs_commit_transaction(). For whatever reason, the transaction

Re: A lot warnings in dmesg while running thunderbird

On 07/20/2016 01:50 PM, Gabriel C wrote: After 24h of running the program and thundirbird all is still fine here. I let it run one more day.. But looks very good. Thanks for your time in helping to track this down. It'll go into the next merge window and be cc'd to stable. -chris -- To

[PATCH] Btrfs: fix delalloc accounting after copy_from_user faults

math again, bringing it much closer to the way it was before the sectorsize conversion Chandan did. The problem is accounting for the offset into the page/sector when we do a partial copy. This one just uses the dirty_sectors variable which should already be updated properly. Signed-off-by: Chris

[PATCH] Btrfs: avoid deadlocks during reservations in btrfs_truncate_block

From: Josef Bacik <jba...@fb.com> The new enospc code makes it possible to deadlock if we don't use FLUSH_LIMIT during reservations inside a transaction. This enforces the correct flush type to avoid both deadlocks and assertions Signed-off-by: Chris Mason <c...@fb.com> Signed-o

Re: A lot warnings in dmesg while running thunderbird

On 07/19/2016 08:11 PM, Gabriel C wrote: On 19.07.2016 13:05, Chris Mason wrote: On Mon, Jul 11, 2016 at 11:28:01AM +0530, Chandan Rajendra wrote: Hi Chris, I am able to reproduce the issue with the 'short-write' program. But before the call trace associated with btrfs_destroy_inode(), I

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

On 07/19/2016 12:06 PM, Chandan Rajendra wrote: On Monday, July 18, 2016 03:31:04 PM Omar Sandoval wrote: Yeah, this should definitely not work. It's possible that things are just silently failing and getting corrupted if the module isn't built with CONFIG_BTRFS_ASSERT, but btrfsck v4.6.1 + my

Re: A lot warnings in dmesg while running thunderbird

On Mon, Jul 11, 2016 at 11:28:01AM +0530, Chandan Rajendra wrote: Hi Chris, I am able to reproduce the issue with the 'short-write' program. But before the call trace associated with btrfs_destroy_inode(), I see the following call trace ... [ cut here ] WARNING: CPU: 2

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

On 07/17/2016 08:19 AM, Chandan Rajendra wrote: On Friday, July 15, 2016 12:15:15 PM Omar Sandoval wrote: On Fri, Jul 15, 2016 at 12:34:10PM +0530, Chandan Rajendra wrote: On Thursday, July 14, 2016 07:47:04 PM Chris Mason wrote: On 07/14/2016 07:31 PM, Omar Sandoval wrote: From: Omar

Re: A lot warnings in dmesg while running thunderbird

On 07/15/2016 03:35 PM, Chris Mason wrote: On 07/07/2016 06:24 AM, Gabriel C wrote: Hi, while running thunderbird on linux 4.6.3 and 4.7.0-rc6 ( didn't tested other versions ) I trigger the following : [ 6393.305675] WARNING: CPU: 6 PID: 5870 at fs/btrfs/inode.c:9306 btrfs_destroy_inode

Re: A lot warnings in dmesg while running thunderbird

On 07/07/2016 06:24 AM, Gabriel C wrote: Hi, while running thunderbird on linux 4.6.3 and 4.7.0-rc6 ( didn't tested other versions ) I trigger the following : [ 6393.305675] WARNING: CPU: 6 PID: 5870 at fs/btrfs/inode.c:9306 btrfs_destroy_inode+0x22e/0x2a0 [btrfs] Every time I've

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

On 07/15/2016 12:28 PM, Goffredo Baroncelli wrote: On 2016-07-14 23:20, Chris Mason wrote: 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"

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

On 07/15/2016 11:10 AM, Andrei Borzenkov wrote: 15.07.2016 16:20, Chris Mason пишет: Interesting, thanks for taking the time to write this up. Is the failure specific to scrub? Or is parity rebuild in general also failing in this case? How do you rebuild parity without scrub as long

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

On 07/15/2016 12:39 AM, Andrei Borzenkov wrote: 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

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

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 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: [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 <dste...@suse.com> Reviewed-by:

Re: [PATCH v2] Btrfs: fix panic in balance due to EIO

ery beginning of build_backref_tree(). Signed-off-by: Liu Bo <bo.li@oracle.com> Signed-off-by: Chris Mason <c...@fb.com> -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org Mor

Re: [PATCH] Btrfs: fix panic in balance due to EIO

On 07/11/2016 08:37 PM, Liu Bo wrote: During build_backref_tree(), if we fail to read a btree node, we can eventually run into BUG_ON(cache->nr_nodes) that we put in backref_cache_cleanup(), meaning we have at least one memory leak. This frees the backref_node that we allocate at the very

Re: [PATCH v3] Btrfs: fix eb memory leak due to readpage failure

On Mon, Jul 11, 2016 at 03:48:38PM -0700, Liu Bo wrote: On Mon, Jul 11, 2016 at 02:27:39PM -0400, Chris Mason wrote: On 07/11/2016 01:39 PM, Liu Bo wrote: > eb->io_pages is set in read_extent_buffer_pages(). > > In case of readpage failure, for pages that have been added to bio

Re: [PATCH v2] Btrfs: fix unexpected balance crash due to BUG_ON

the cancel job. Reported-by: sash <master.b.at.ra...@chefmail.de> Signed-off-by: Liu Bo <bo.li@oracle.com> v2 Looks good, thanks Liu. Signed-off-by: Chris Mason <c...@fb.com> -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the

Re: [PATCH v3] Btrfs: fix eb memory leak due to readpage failure

On 07/11/2016 01:39 PM, Liu Bo wrote: eb->io_pages is set in read_extent_buffer_pages(). In case of readpage failure, for pages that have been added to bio, it calls bio_endio and later readpage_io_failed_hook() does the work. When this eb's page (couldn't be the 1st page) fails to add

Re: stat() on btrfs reports the st_blocks with delay (data loss in archivers)

On 07/11/2016 11:16 AM, David Sterba wrote: On Mon, Jul 11, 2016 at 11:00:55AM -0400, Chris Mason wrote: So, the real bug is that we're letting some delalloc stat hang around after the truncate, probably related to IO in progress. We do already account for delalloc in what we return to stat

Re: stat() on btrfs reports the st_blocks with delay (data loss in archivers)

On 07/11/2016 10:41 AM, David Sterba wrote: On Sat, Jul 02, 2016 at 09:18:07AM +0200, Pavel Raiskup wrote: There are optimizations in archivers (tar, rsync, ...) that rely on up2date st_blocks info. For example, in GNU tar there is optimization check [1] whether the 'st_size' reports more

Re: A lot warnings in dmesg while running thunderbird

On Mon, Jul 11, 2016 at 11:28:01AM +0530, Chandan Rajendra wrote: On Friday, July 08, 2016 12:02:35 PM Chris Mason wrote: Can you please run the attached test program: gcc -o short-write short-write.c -lpthread ./short-write some-new-file-on-btrfs I want to see if you're triggering the same

Re: A lot warnings in dmesg while running thunderbird

On 07/08/2016 11:02 AM, Gabriel C wrote: On 08.07.2016 14:41, Chris Mason wrote: On 07/08/2016 05:57 AM, Gabriel C wrote: 2016-07-07 21:21 GMT+02:00 Chris Mason <c...@fb.com>: On 07/07/2016 06:24 AM, Gabriel C wrote: Hi, while running thunderbird on linux 4.6.3 and 4.7

Re: errors with linux-next-20160701

On 07/08/2016 09:51 AM, David Sterba wrote: On Thu, Jul 07, 2016 at 08:15:18PM +0200, Laszlo Fiat wrote: I have a simple btrfs filesystem on a single device. It worked well so far. Recently I compiled a new kernel linux-next-20160701, with this new kernel I get warnings and errors in the

Re: A lot warnings in dmesg while running thunderbird

On 07/08/2016 05:57 AM, Gabriel C wrote: 2016-07-07 21:21 GMT+02:00 Chris Mason <c...@fb.com>: On 07/07/2016 06:24 AM, Gabriel C wrote: Hi, while running thunderbird on linux 4.6.3 and 4.7.0-rc6 ( didn't tested other versions ) I trigger the following : I definitely thought

Re: A lot warnings in dmesg while running thunderbird

On 07/07/2016 06:24 AM, Gabriel C wrote: Hi, while running thunderbird on linux 4.6.3 and 4.7.0-rc6 ( didn't tested other versions ) I trigger the following : I definitely thought we had this fixed in v4.7-rc. Can you easily fsck this filesystem? Something strange is going on. -chris

Re: [PATCH 05/14] Btrfs: warn_on for unaccounted spaces

On 06/27/2016 12:47 AM, Qu Wenruo wrote: Hi Josef, Would you please move this patch to the first of the patchset? It's making bisect quite hard, as it will always stop at this patch, hard to check if it's a regression or existing bug. That's a good idea. Which workload are you having

[GIT PULL 2/2] Btrfs

Hi Linus, Btrfs part two was supposed to be a single patch on part of v4.7-rc4. Somehow I didn't notice that my part2 branch repeated a few of the patches in part 1 when I set it up earlier this week. Cherry-picking gone wrong as I folded a fix into Dave Sterba's original integration. I've been

[GIT PULL 1/2] Btrfs

improvement on pretty much every workload. Josef Bacik (2) commits (+38/-27): Btrfs: don't do nocow check unless we have to (+22/-22) Btrfs: track transid for delayed ref flushing (+16/-5) Liu Bo (1) commits (+11/-2): Btrfs: fix error handling in map_private_extent_buffer Chris Mason (1

Re: [PULL] Btrfs updates for 4.7-rc5

On 06/23/2016 06:56 AM, David Sterba wrote: Hi, this is hopefully the last pull for 4.7 from me. There are two fixes that should finalize the changes introduced in this dev cycle, plus some minor independent fixes. The following changes since commit 33688abb2802ff3a230bd2441f765477b94cc89e:

Re: [PATCH v3 2/2] btrfs: make sure device is synced before return

On 06/23/2016 08:54 AM, Anand Jain wrote: An inconsistent behavior due to stale reads from the disk was reported mail-archive.com/linux-btrfs@vger.kernel.org/msg54188.html This patch will make sure devices are synced before return in the unmount thread. Signed-off-by: Anand Jain

Re: [PATCH v2 2/2] btrfs: wait for bdev put

On Wed, Jun 22, 2016 at 6:18 AM, Anand Jain <anand.j...@oracle.com> wrote: Thanks for the review Chris. On 06/21/2016 09:00 PM, Chris Mason wrote: On 06/21/2016 06:24 AM, Anand Jain wrote: From: Anand Jain <anand.j...@oracle.com> Further t

Re: [PATCH v2 2/2] btrfs: wait for bdev put

On 06/21/2016 06:24 AM, Anand Jain wrote: From: Anand Jain Further to the commit bc178622d40d87e75abc131007342429c9b03351 btrfs: use rcu_barrier() to wait for bdev puts at unmount This patch implements a method to time wait on the __free_device() which

Re: [PATCH 2/2] btrfs: prefix fsid to all trace events

On Thu, Jun 09, 2016 at 07:48:01PM -0400, je...@suse.com wrote: > From: Jeff Mahoney > > When using trace events to debug a problem, it's impossible to determine > which file system generated a particular event. This patch adds a > macro to prefix standard information to the

[GIT PULL] Btrfs

Hi Linus My for-linus-4.7 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.7 Has some fixes and some new self tests for btrfs. The self tests are usually disabled in the .config file (unless you're doing btrfs dev work), and this bunch is meant to find

[GIT PULL] Btrfs

) Chris Mason (1) commits (+12/-1): Btrfs: deal with duplciates during extent_map insertion in btrfs_get_extent Total: (9) commits (+105/-20) fs/btrfs/extent-tree.c | 6 ++ fs/btrfs/extent_io.c| 10 ++ fs/btrfs/inode.c| 13 - fs/btrfs/ordered-data.c | 6

Re: [GIT PULL] Device replace fixes

On Wed, Jun 01, 2016 at 12:44:13PM +0100, fdman...@kernel.org wrote: > From: Filipe Manana > > Hi Chris, > > Please consider the following device replace related fixes for inclusion > in a future 4.7 release candidate kernel. These were all previously sent > to the mailing

Re: [RFC] strace patches for new ioctls

On Tue, May 31, 2016 at 04:41:55PM -0400, Jeff Mahoney wrote: > Hi all - > > Strace 4.12 was tagged for release today and it supports decoding of > btrfs ioctls. I'd like to propose a requirement that future ioctl > additions come with a patch to strace as well so we don't get out of sync. > >

Re: [PULL] Btrfs for 4.7, part 2

On Sat, May 28, 2016 at 01:14:13PM +0800, Anand Jain wrote: On 05/27/2016 11:42 PM, Chris Mason wrote: I'm getting errors from btrfs fi show -d, after the very last round of device replaces. A little extra debugging: bytenr mismatch, want=4332716032, have=0 ERROR: cannot read chunk root

[GIT PULL] Btrfs

find_workspace always succeed (+12/-8) btrfs: preallocate compression workspaces (+16/-0) Liu Bo (2) commits (+7/-3): Btrfs: fix unexpected return value of fiemap (+5/-1) Btrfs: free sys_array eb as soon as possible (+2/-2) Chris Mason (1) commits (+17/-10): Btrfs: fix handling of faults from

Re: [PULL] Btrfs for 4.7, part 2

On Fri, May 27, 2016 at 10:35:27AM -0400, Chris Mason wrote: > On Fri, May 27, 2016 at 01:18:22PM +0200, David Sterba wrote: > > On Thu, May 26, 2016 at 08:14:14PM -0400, Chris Mason wrote: > > > On Thu, May 26, 2016 at 11:27:06AM +0200, David Sterba wrote: > > > > Hi

Re: [PULL] Btrfs for 4.7, part 2

On Fri, May 27, 2016 at 01:18:22PM +0200, David Sterba wrote: > On Thu, May 26, 2016 at 08:14:14PM -0400, Chris Mason wrote: > > On Thu, May 26, 2016 at 11:27:06AM +0200, David Sterba wrote: > > > Hi, > > > > > > please pull a few more patches that

Re: [PULL] Btrfs for 4.7, part 2

On Thu, May 26, 2016 at 11:27:06AM +0200, David Sterba wrote: > Hi, > > please pull a few more patches that did not go to pull #1 for 4.7, minor > cleanups and fixes. Thanks. Thanks Dave! Trying to figure out why we're failing btrfs/011, but I don't see how it could be related to this bunch.

Re: mixed inline, non-inline extents leading to EIO when reading small files

ne xfs_io -c "pread 0 1000" -c "fadvise -d 0 1000" -c "pread 0 1000" inline xfs_io -c "fadvise -d 0 1000" inline cat inline You'll get EIOs trying to read inline after this because add_extent_map is returning EEXIST Signed-off-by: Chris Mason <c...@fb.c

Re: [PATCH] Btrfs: fix ->iterate_shared() by upgrading i_rwsem for delayed nodes

On Wed, May 25, 2016 at 10:11:29PM +0200, David Sterba wrote: > On Fri, May 20, 2016 at 01:50:33PM -0700, Omar Sandoval wrote: > > Commit fe742fd4f90f ("Revert "btrfs: switch to ->iterate_shared()"") > > backed out the conversion to ->iterate_shared() for Btrfs because the > > delayed inode

[GIT PULL] Btrfs

Hi Linus, My for-linus-4.7 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.7 Has our merge window series of cleanups and fixes. These target a wide range of issues, but do include some important fixes for qgroups, O_DIRECT, and fsync handling. Jeff

Re: [PATCH] Btrfs: fix handling of faults from btrfs_copy_from_user

On Tue, May 17, 2016 at 10:47:27PM +0200, Adam Borowski wrote: > On Tue, May 17, 2016 at 12:23:44PM -0400, Chris Mason wrote: > > On Tue, May 17, 2016 at 05:14:51PM +0200, Adam Borowski wrote: > > > On Mon, May 16, 2016 at 05:06:55PM -0400, Chris Mason wrote: > > &

Re: Crash after WARN_ON(BTRFS_I(inode)->csum_bytes)

On Thu, May 19, 2016 at 12:25:53PM +0200, M G Berberich wrote: > Hello, > > a near total system crash (reboot via magic-sysreq-keys was possible) > which seems to be associated to btrfs. > > btrfs check (v 4.5.2) does not find any problem with any filesystems > on the system. > > Kernel is

incoming merge conflict to linux-next

Hi Stephen, Dave Sterba's tree in linux-next has a few btrfs patches that we're not sending yet into Linus. We've got an update for Josef's enospc work that'll get sent in next week. So he prepped a pull for me that merged up a number of his branches but didn't include Josef's new code. It has

Re: [PATCH] Btrfs: fix handling of faults from btrfs_copy_from_user

On Tue, May 17, 2016 at 11:57:07PM +0200, Adam Borowski wrote: > On Tue, May 17, 2016 at 05:00:49PM -0400, Chris Mason wrote: > > On Tue, May 17, 2016 at 10:47:27PM +0200, Adam Borowski wrote: > > > > Hmmm, some of your traces mentioned compression, do you have compre

Re: [PATCH] Btrfs: fix handling of faults from btrfs_copy_from_user

On Tue, May 17, 2016 at 10:47:27PM +0200, Adam Borowski wrote: > On Tue, May 17, 2016 at 12:23:44PM -0400, Chris Mason wrote: > > On Tue, May 17, 2016 at 05:14:51PM +0200, Adam Borowski wrote: > > > On Mon, May 16, 2016 at 05:06:55PM -0400, Chris Mason wrote: > > &

Re: [PATCH] Btrfs: fix handling of faults from btrfs_copy_from_user

On Tue, May 17, 2016 at 05:14:51PM +0200, Adam Borowski wrote: > On Mon, May 16, 2016 at 05:06:55PM -0400, Chris Mason wrote: > > Hi everyone, > > > > I've tried to cc most of the recent reports of this warning. It was > > pretty hard to track down, but I've got a t

Re: [PULL] Btrfs for 4.7

On Mon, May 16, 2016 at 04:14:23PM +0200, David Sterba wrote: > Hi, > > please queue the following branch to 4.7. > > New features or user-visible changes: > * device delete by id, a v2 ioctl for device deletion (this was held back from > 4.6 pull due to possibly related crashes that haven't

[PATCH] Btrfs: fix handling of faults from btrfs_copy_from_user

; } ret = unlink(filename); if (ret) { perror("unlink"); exit(1); } } return 0; } Signed-off-by: Chris Mason <c...@fb.com> Reported-by: Dave Jones <d...@fb

Re: WARNING at fs/btrfs/inode.c:9261 btrfs_destroy_inode()

On Tue, May 10, 2016 at 06:19:20PM -0500, Eric Biggers wrote: > Hello, > > The following warning has been triggering for me since about v4.6-rc3: > > WARN_ON(BTRFS_I(inode)->csum_bytes); > > On one machine the warning has occurred 657 times since v4.6-rc5. On another > it > has occurred

Re: [PATCH 1/2] Btrfs: fix race between fsync and direct IO writes for prealloc extents

On Wed, May 11, 2016 at 09:10:12AM -0700, Josef Bacik wrote: > On 05/11/2016 09:05 AM, Chris Mason wrote: > >On Wed, May 11, 2016 at 04:56:56PM +0100, Filipe Manana wrote: > >>On Wed, May 11, 2016 at 4:41 PM, Josef Bacik <jba...@fb.com> wrote: > >>>On 05/09/2016

Re: [PATCH 1/2] Btrfs: fix race between fsync and direct IO writes for prealloc extents

On Wed, May 11, 2016 at 04:56:56PM +0100, Filipe Manana wrote: > On Wed, May 11, 2016 at 4:41 PM, Josef Bacik wrote: > > On 05/09/2016 07:01 AM, fdman...@kernel.org wrote: > >> > >> From: Filipe Manana > >> > >> When we do a direct IO write against a

Re: About in-band dedupe for v4.7

On Tue, May 10, 2016 at 03:19:52PM +0800, Qu Wenruo wrote: > Hi, Chris, Josef and David, > > As merge window for v4.7 is coming, it would be good to hear your ideas > about the inband dedupe. > > We are addressing the ENOSPC problem which Josef pointed out, and we believe > the final fix patch

Re: WARNING at fs/btrfs/inode.c:9261 btrfs_destroy_inode()

On Tue, May 10, 2016 at 06:19:20PM -0500, Eric Biggers wrote: > Hello, > > The following warning has been triggering for me since about v4.6-rc3: > > WARN_ON(BTRFS_I(inode)->csum_bytes); > > On one machine the warning has occurred 657 times since v4.6-rc5. On another > it > has occurred

Re: [PATCH] Btrfs: track transid for delayed ref flushing

this mistake every year or so. Subject: [PATCH] btrfs: fix deadlock in delayed_ref_async_start "Btrfs: track transid for delayed ref flushing" was deadlocking on btrfs_attach_transaction because its not safe to call from the async delayed ref start code. This commit brings back btrfs_j

Re: 4.6.0-rc3+: WARNING: CPU: 16 PID: 17257 at fs/btrfs/inode.c:9261 btrfs_destroy_inode

On Wed, Apr 27, 2016 at 02:25:50PM +0200, Christian Borntraeger wrote: > Folks, > > I can sometimes trigger the following bug > > [ 244.493534] [ cut here ] > [ 244.493624] WARNING: CPU: 16 PID: 17257 at fs/btrfs/inode.c:9261 > btrfs_destroy_inode+0x288/0x2b0 [btrfs] >

Re: [PATCH v8 00/27][For 4.7] Btrfs: Add inband (write time) de-duplication framework

On Wed, Apr 20, 2016 at 10:02:27AM +0800, Qu Wenruo wrote: > Hi David, > > Any new comment about the ondisk format and ioctl interface? Hi Qu, I'm at LSF this week but will dig through again on the way home. Thanks! -chris -- To unsubscribe from this list: send the line "unsubscribe

[GIT PULL] Btrfs

Hi Linus We have some fixes queued up in my for-linus-4.6 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.6 These are bug fixes, including a really old fsync bug, and a few trace points to help us track down problems in the quota code. Mark Fasheh (2)

Re: [PATCH] [RFC] fix potential access after free: return value of blk_check_plugged() must be used schedule() safe

On Tue, Apr 05, 2016 at 03:36:57PM +0200, Lars Ellenberg wrote: > blk_check_plugged() will return a pointer > to an object linked on current->plug->cb_list. > > That list may "at any time" be implicitly cleared by > blk_flush_plug_list() > flush_plug_callbacks() > either as a result of

[GIT PULL] Btrfs

Hi Linus, My for-linus-4.6 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.6 Has a few fixes Dave Sterba had queued up. These are all pretty small, but since they were tested I decided against waiting for more: Alex Lyakas (2) commits (+18/-10):

Re: [PATCH v2] Btrfs: fix file/data loss caused by fsync after rename and new inode

On Wed, Mar 30, 2016 at 11:37:21PM +0100, fdman...@kernel.org wrote: > From: Filipe Manana > > If we rename an inode A (be it a file or a directory), create a new > inode B with the old name of inode A and under the same parent directory, > fsync inode B and then power fail,

Re: [PATCH] Btrfs: fix crash/invalid memory access on fsync when using overlayfs

tories belong to btrfs filesystems. > > This issue has been reported several times by users in the mailing list > and bugzilla. A test case for xfstests is being submitted as well. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101951 > Bugzilla: https://bugzilla.ke

Re: [PATCH v8 10/27] btrfs: dedupe: Add basic tree structure for on-disk dedupe method

On Sat, Mar 26, 2016 at 09:11:53PM +0800, Qu Wenruo wrote: > > > On 03/25/2016 11:11 PM, Chris Mason wrote: > >On Fri, Mar 25, 2016 at 09:59:39AM +0800, Qu Wenruo wrote: > >> > >> > >>Chris Mason wrote on 2016/03/24 16:58 -0400: > >>

Re: [PATCH] Btrfs: fix crash/invalid memory access on fsync when using overlayfs

On Mon, Mar 21, 2016 at 05:52:44PM +, Filipe Manana wrote: > On Mon, Mar 21, 2016 at 5:51 PM, Chris Mason <c...@fb.com> wrote: > > On Mon, Mar 21, 2016 at 05:38:44PM +, fdman...@kernel.org wrote: > >> From: Filipe Manana <fdman...@suse.com> > >&g

Re: [PATCH v8 25/27] btrfs: dedupe: Add support for compression and dedpue

On Fri, Mar 25, 2016 at 09:44:31AM +0800, Qu Wenruo wrote: > > > Chris Mason wrote on 2016/03/24 16:35 -0400: > >On Tue, Mar 22, 2016 at 09:35:50AM +0800, Qu Wenruo wrote: > >>From: Wang Xiaoguang <wangxg.f...@cn.fujitsu.com> > >> > >>The basi

Re: [PATCH v8 10/27] btrfs: dedupe: Add basic tree structure for on-disk dedupe method

On Fri, Mar 25, 2016 at 09:59:39AM +0800, Qu Wenruo wrote: > > > Chris Mason wrote on 2016/03/24 16:58 -0400: > >Are you storing the entire hash, or just the parts not represented in > >the key? I'd like to keep the on-disk part as compact as possible for > >this

Re: [PATCH v8 10/27] btrfs: dedupe: Add basic tree structure for on-disk dedupe method

On Tue, Mar 22, 2016 at 09:35:35AM +0800, Qu Wenruo wrote: > Introduce a new tree, dedupe tree to record on-disk dedupe hash. > As a persist hash storage instead of in-memeory only implement. > > Unlike Liu Bo's implement, in this version we won't do hack for > bytenr -> hash search, but add a

Re: [PATCH v8 25/27] btrfs: dedupe: Add support for compression and dedpue

On Tue, Mar 22, 2016 at 09:35:50AM +0800, Qu Wenruo wrote: > From: Wang Xiaoguang > > The basic idea is also calculate hash before compression, and add needed > members for dedupe to record compressed file extent. > > Since dedupe support dedupe_bs larger than 128K,

Re: [GIT PULL] Btrfs

On Mon, Mar 21, 2016 at 10:15:33PM -0400, Chris Mason wrote: > On Mon, Mar 21, 2016 at 06:16:54PM -0700, Linus Torvalds wrote: > > On Mon, Mar 21, 2016 at 5:24 PM, Chris Mason <c...@fb.com> wrote: > > > > > > I waited an extra day to send this one out because I

Re: [GIT PULL] Btrfs

On Mon, Mar 21, 2016 at 06:16:54PM -0700, Linus Torvalds wrote: > On Mon, Mar 21, 2016 at 5:24 PM, Chris Mason <c...@fb.com> wrote: > > > > I waited an extra day to send this one out because I hit a crash late > > last week with CONFIG_DEBUG_PAGEALLOC enabled (fixed i

[GIT PULL] Btrfs

Satoru Takeuchi (1) commits (+3/-0): Btrfs: Show a warning message if one of objectid reaches its highest value Ashish Samant (1) commits (+6/-1): btrfs: Print Warning only if ENOSPC_DEBUG is enabled Sudip Mukherjee (1) commits (+1/-1): btrfs: fix build warning Chris Mason (1) commits (+10/-0

Re: [PATCH] Btrfs: fix crash/invalid memory access on fsync when using overlayfs

On Mon, Mar 21, 2016 at 06:58:08PM +0100, David Sterba wrote: > On Mon, Mar 21, 2016 at 01:51:07PM -0400, Chris Mason wrote: > > On Mon, Mar 21, 2016 at 05:38:44PM +, fdman...@kernel.org wrote: > > > From: Filipe Manana <fdman...@suse.com> > > > >

Re: [PATCH] Btrfs: fix crash/invalid memory access on fsync when using overlayfs

On Mon, Mar 21, 2016 at 05:38:44PM +, fdman...@kernel.org wrote: > From: Filipe Manana > > If the lower or upper directory of an overlayfs mount belong to a btrfs > file system and we fsync the file through the overlayfs' merged directory > we ended up accessing an inode

[PATCH] btrfs: make sure we stay inside the bvec during __btrfs_lookup_bio_sums

vec deref is never actually used for anything. But CONFIG_DEBUG_PAGEALLOC catches it because we're outside our bio. Signed-off-by: Chris Mason <c...@fb.com> Reviewed-by: David Sterba <dste...@suse.com> --- fs/btrfs/file-item.c | 10 ++ 1 file changed, 10 insertions(+) diff -

Re: [PULL] Btrfs cleanups for 4.6, part 2

On Tue, Mar 15, 2016 at 02:50:14PM +0100, David Sterba wrote: > Hi, > > a few more cleanups sent recently and some that I found in my inbox marked but > not processed. Based on top of current integration. Please pull, thanks. Thanks Dave, I'll get these pulled in and restart my long stress run.

[GIT PULL] Btrfs

Hi Linus, We've got a fix in my for-linus-4.5 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.5 Filipe nailed down a problem where tree log replay would do some work that orphan code wasn't expecting to be done yet, leading to BUG_ON. Filipe Manana (1)

Re: Stray 4k extents with slow buffered writes

On Thu, Mar 03, 2016 at 01:28:29PM +0100, Holger Hoffstätte wrote: > > Here's an observation that is not a bug (as in data corruption), just > somewhat odd and unnecessary behaviour. It could be considered a > performance or scalability bug. > > I've noticed that slow slow buffered writes

Re: [GIT PULL] Btrfs fixes for 4.6

On Wed, Mar 02, 2016 at 09:24:46AM +0800, Qu Wenruo wrote: > > > Chris Mason wrote on 2016/03/01 20:11 -0500: > >On Wed, Mar 02, 2016 at 08:48:06AM +0800, Qu Wenruo wrote: > >> > >> > >>Chris Mason wrote on 2016/03/01 11:06 -0500: > >>>On Tue

Re: [GIT PULL] Btrfs fixes for 4.6

On Wed, Mar 02, 2016 at 08:48:06AM +0800, Qu Wenruo wrote: > > > Chris Mason wrote on 2016/03/01 11:06 -0500: > >On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote: > >>Hi Chris, > >> > >>On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@ke

Re: [RFC] Experimental btrfs encryption

On Tue, Mar 01, 2016 at 09:59:27AM -0800, Christoph Hellwig wrote: > On Tue, Mar 01, 2016 at 11:46:16AM -0500, Chris Mason wrote: > > We'll definitely move in line with the common API over time. Thanks > > Anand for starting this! > > > > I'd prefer that we keep it

Re: [RFC] Experimental btrfs encryption

On Tue, Mar 01, 2016 at 05:29:52PM +0100, Tomasz Torcz wrote: > On Wed, Mar 02, 2016 at 12:08:09AM +0800, Anand Jain wrote: > > This patchset adds btrfs encryption support. > > > > Warning: > > The code is in prototype/experimental stage and is not suitable > > for the production data yet. > >

Re: [GIT PULL] Btrfs fixes for 4.6

On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote: > Hi Chris, > > On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote: > > The following changes since commit 0fcb760afa6103419800674e22fb7f4de1f9670b: > > > > Merge branch 'for-next' of > >

Re: [PATCH 1/3] btrfs: Continue write in case of can_not_nocow

On Fri, Feb 26, 2016 at 10:41:31AM +0500, Roman Mamedov wrote: > On Wed, 6 Jan 2016 19:00:17 +0800 > Zhao Lei wrote: > > > btrfs failed in xfstests btrfs/080 with -o nodatacow. > > > > Can be reproduced by following script: > > DEV=/dev/vdg > > MNT=/mnt/tmp > > > >

Re: Can you help explain these OOM crashes?

On Thu, Feb 25, 2016 at 11:20:29AM -0800, Marc MERLIN wrote: > Which kind of RAM am I missing? :) > > Thanks, > Marc > > [46320.200703] btrfs: page allocation failure: order:1, mode:0x2204020 > [46320.221174] CPU: 7 PID: 12576 Comm: btrfs Not tainted > 4.4.2-amd64-i915-volpreempt-20160213bc1 #3

[GIT PULL] Btrfs

Hi Linus, My for-linus-4.5 branch has a btrfs DIO error passing fix. I know how much you love DIO, so I'm going to suggest against reading it. We'll follow up with a patch to drop the error arg from dio_end_io in the next merge window.

Re: [PATCH] btrfs: change max_inline default to 2048

On Thu, Feb 11, 2016 at 05:55:30PM +0100, David Sterba wrote: > The current practical default is ~4k on x86_64 (the logic is more complex, > simplified for brevity), the inlined files land in the metadata group and > thus consume space that could be needed for the real metadata. > > The inlining

[GIT PULL] Btrfs

Hi Linus, Please pull my for-linus-4.5 branch: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.5 This has a few fixes from Filipe, along with a readdir fix from Dave that we've been testing for some time. Filipe Manana (4) commits (+115/-68): Btrfs: remove

Re: [PATCH] Btrfs: fix hang on extent buffer lock caused by the inode_paths ioctl

On Wed, Feb 03, 2016 at 11:24:33PM +, Filipe Manana wrote: > On Wed, Feb 3, 2016 at 11:19 PM, Liu Bo wrote: > > On Wed, Feb 03, 2016 at 08:26:50PM +, fdman...@kernel.org wrote: > >> So fix this by avoiding doing the nested read lock, which is easily > >> avoidable.

Re: [PATCH 0/7] Let user specify the kernel version for features

On Wed, Feb 03, 2016 at 11:50:38AM +0100, David Sterba wrote: > Going back to this discussion, > > On Mon, Nov 30, 2015 at 01:46:15PM +0800, Qu Wenruo wrote: > > To be honest, how many guys really unhappy with current default features > > behavior *except* you? > > Me too. > > Anand's summary

Re: [PATCH] Btrfs: fix race between free space endio workers and space cache writeout

On Wed, Dec 30, 2015 at 04:02:04PM +, fdman...@kernel.org wrote: > From: Filipe Manana > > While running a stress test I ran into the following trace/transaction > abort: > > [471626.672243] [ cut here ] > [471626.673322] WARNING: CPU: 9 PID: 19107

<    1   2   3   4   5   6   7   8   9   10   >