At 06/25/2016 01:45 PM, Chandan Rajendra wrote:

On Saturday, June 25, 2016 09:22:44 AM Qu Wenruo wrote:

quoted

On 06/24/2016 05:29 PM, Chandan Rajendra wrote:

quoted

On Friday, June 24, 2016 10:50:41 AM Qu Wenruo wrote:

quoted

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.

quoted

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.

Thanks　for your info.

Confirmed that leaked space is unrelated to your sub page size.

It's another patchset causing the bug.
Bisected and I'll inform the author.

Great thanks for your help.
Qu