From: Chandan Rajendra <chandan@linux.vnet.ibm.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Qu Wenruo <quwenruo@cn.fujitsu.com>,
dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v11 00/13] Btrfs dedupe framework
Date: Sat, 25 Jun 2016 11:15:39 +0530 [thread overview]
Message-ID: <1761846.d56ix9Vzn2@localhost.localdomain> (raw)
In-Reply-To: <fe84125c-12e6-3425-7948-73819a891e77@gmx.com>
On Saturday, June 25, 2016 09:22:44 AM Qu Wenruo wrote:
>
> On 06/24/2016 05:29 PM, Chandan Rajendra wrote:
> > On Friday, June 24, 2016 10:50:41 AM Qu Wenruo wrote:
> >> Hi Chandan, David,
> >>
> >> When I'm trying to rebase dedupe patchset on top of Chadan's sub page
> >> size patchset (using David's for-next-test-20160620), although the
> >> rebase itself is quite simple, but I'm afraid that I found some bugs for
> >> sub page size patchset, *without* dedupe patchset applied.
> >>
> >> These bugs seems to be unrelated to each other
> >> 1) state leak at btrfs rmmod time
> >
> > The leak was due to not freeing 'cached_state' in
> > read_extent_buffer_pages(). I have fixed this and the fix will be part of the
> > patchset when I post the next version to the mailing list.
> >
> > I have always compiled the btrfs code as part of the vmlinux image and hence
> > have never rmmod the btrfs module during my local testing. The space leak
> > messages might have appeared when I shut down my guest. Hence I had never
> > noticed them before. Thanks once again for informing me about it.
> >
> >> 2) bytes_may_use leak at qgroup EDQUOTA error time
> >
> > I have a slightly older version of btrfs-progs which does not yet have btrfs
> > dedupe" command. I will get the new version and check if the space leak can be
> > reproduced on my machine.
> >
> > However, I don't see the space leak warning messages when the reproducer
> > script is executed after commenting out "btrfs dedupe enable $mnt".
>
> Strange.
> That dedupe command is not useful at all, as I'm using the branch
> without the dedupe patchset.
> Even with btrfs-progs dedupe patchset, dedupe enable only output ENOTTY
> error message.
>
> I'll double check if it's related to the dedupe.
>
> BTW, are you testing with 4K page size?
Yes, I executed the script with 4k page size. I had based my patchset on top
of 4.7-rc2 kernel. If you are interested, you can get the kernel sources at
'https://github.com/chandanr/linux subpagesize-blocksize'.
I will soon rebase my patchset on David's master branch. I will let you know
if I hit the space leak issue on the rebased kernel.
--
chandan
next prev parent reply other threads:[~2016-06-25 5:45 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-15 2:09 [PATCH v11 00/13] Btrfs dedupe framework Qu Wenruo
2016-06-15 2:09 ` [PATCH v11 01/13] btrfs: dedupe: Introduce dedupe framework and its header Qu Wenruo
2016-06-15 2:09 ` [PATCH v11 02/13] btrfs: dedupe: Introduce function to initialize dedupe info Qu Wenruo
2016-06-15 2:09 ` [PATCH v11 03/13] btrfs: dedupe: Introduce function to add hash into in-memory tree Qu Wenruo
2016-06-15 2:09 ` [PATCH v11 04/13] btrfs: dedupe: Introduce function to remove hash from " Qu Wenruo
2016-06-15 2:09 ` [PATCH v11 05/13] btrfs: delayed-ref: Add support for increasing data ref under spinlock Qu Wenruo
2016-06-15 2:09 ` [PATCH v11 06/13] btrfs: dedupe: Introduce function to search for an existing hash Qu Wenruo
2016-06-15 2:09 ` [PATCH v11 07/13] btrfs: dedupe: Implement btrfs_dedupe_calc_hash interface Qu Wenruo
2016-06-15 2:09 ` [PATCH v11 08/13] btrfs: ordered-extent: Add support for dedupe Qu Wenruo
2016-06-15 2:09 ` [PATCH v11 09/13] btrfs: dedupe: Inband in-memory only de-duplication implement Qu Wenruo
2016-06-15 2:09 ` [PATCH v11 10/13] btrfs: dedupe: Add ioctl for inband dedupelication Qu Wenruo
2016-06-15 2:09 ` [PATCH v11 11/13] btrfs: relocation: Enhance error handling to avoid BUG_ON Qu Wenruo
2016-06-15 2:10 ` [PATCH v11 12/13] btrfs: improve inode's outstanding_extents computation Qu Wenruo
2016-06-15 2:10 ` [PATCH v11 13/13] btrfs: dedupe: fix false ENOSPC Qu Wenruo
2016-06-15 3:11 ` kbuild test robot
2016-06-15 3:17 ` [PATCH v11.1 " Qu Wenruo
2016-06-15 3:26 ` [PATCH v11 " kbuild test robot
2016-06-20 16:03 ` [PATCH v11 00/13] Btrfs dedupe framework David Sterba
2016-06-21 0:36 ` Qu Wenruo
2016-06-21 9:13 ` David Sterba
2016-06-21 9:26 ` Qu Wenruo
2016-06-21 9:34 ` David Sterba
2016-06-21 16:55 ` Chandan Rajendra
2016-06-23 12:17 ` David Sterba
2016-06-24 2:50 ` Qu Wenruo
2016-06-24 4:34 ` Chandan Rajendra
2016-06-24 9:29 ` Chandan Rajendra
2016-06-25 1:22 ` Qu Wenruo
2016-06-25 5:45 ` Chandan Rajendra [this message]
2016-06-27 3:04 ` Qu Wenruo
2016-06-24 4:10 ` Chandan Rajendra
2016-06-22 1:48 ` Qu Wenruo
2016-06-24 6:54 ` Satoru Takeuchi
2016-06-24 8:30 ` Qu Wenruo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1761846.d56ix9Vzn2@localhost.localdomain \
--to=chandan@linux.vnet.ibm.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=quwenruo@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.