Re: How to recover a filesystem without formatting nor using the btrfs check command.

At 01/02/2017 07:29 AM, none wrote: Le 2016-10-27 03:11, Qu Wenruo a écrit : At 10/26/2016 07:52 PM, none wrote: Le 2016-10-26 03:43, Qu Wenruo a écrit : Unfortunately, low memory mode is right here. If btrfs-image dump the image correctly, your extent tree is really screwed up. And how

Re: [PATCH v2] fstests: btrfs/006: Fix false alert due to output change

On Mon, Jan 02, 2017 at 10:16:17PM -0500, Su Yue wrote: > Btrfs-progs v4.9 changed "device status" output by adding one more > space, which differs from golden output. > Fix it by using filter '_filter_spaces' to convert multi space into one. You missed your SOB line. I added Signed-off-by: Su

[PATCH v2] fstests: btrfs/006: Fix false alert due to output change

Btrfs-progs v4.9 changed "device status" output by adding one more space, which differs from golden output. Fix it by using filter '_filter_spaces' to convert multi space into one. --- v2: Changed the '_filter_spaces' to match both Tab and Space and tested all related tests. --- common/filter

Re: [PULL REQUEST FOR NEXT PATCH 00/26] Patches from Fujitsu for next version

At 01/03/2017 12:47 AM, David Sterba wrote: On Fri, Dec 30, 2016 at 09:00:36AM +0800, Qu Wenruo wrote: Hi, please fetch the following branch for next branch: https://github.com/adam900710/linux.git fujitsu_for_next This branch contains most of Fujitsu unmerged patches for for-next branch.

Re: [PATCH v2 00/19]

At 12/31/2016 02:39 AM, Goffredo Baroncelli wrote: On 2016-12-30 01:40, Qu Wenruo wrote: Hi Goffredo, [...] So I tried to strace it to check if the program was working properly. The strace output showed me that the program ran correctly. However form the strace I noticed that the program

Re: Will fstrim discard unused parts of chunks?

On Mon, Jan 2, 2017 at 2:05 PM, Chris Murphy wrote: > On Mon, Jan 2, 2017 at 2:02 PM, Jeff Mahoney wrote: >> On 1/2/17 4:55 AM, Andrei Borzenkov wrote: >>> I try to understand what exactly is trimmed in case of btrfs. Using >>> installation in QEMU I see

Re: Will fstrim discard unused parts of chunks?

On Mon, Jan 2, 2017 at 2:02 PM, Jeff Mahoney wrote: > On 1/2/17 4:55 AM, Andrei Borzenkov wrote: >> I try to understand what exactly is trimmed in case of btrfs. Using >> installation in QEMU I see that host file size is about 9GB, allocated >> size in guest approximately matches

Re: Will fstrim discard unused parts of chunks?

On 1/2/17 4:55 AM, Andrei Borzenkov wrote: > I try to understand what exactly is trimmed in case of btrfs. Using > installation in QEMU I see that host file size is about 9GB, allocated > size in guest approximately matches it and used space in guest is 7.6GB. > After some experimenting it looks

Re: [markfasheh/duperemove] Why blocksize is limit to 1MB?

Hi, Before doing that, probably one way to think about it could be, what would be the probablitity of two 100M blocks generate the same hash and be treated as identical. Thanks, Xin     Sent: Monday, January 02, 2017 at 4:32 AM From: "Peter Becker" To: "Xin Zhou"

read-only fs, kernel 4.9.0, fs/btrfs/delayed-inode.c:1170 __btrfs_run_delayed_items,

Attempt 2. The original post isn't showing up on spinics, just my followup. The Problem: The file system goes read-only soon after startup. It only happens with a particular subvolume used for root fs, and only with kernel 4.9.0 and 4.10-rc1. If I boot kernel 4.8.15 with this subvolume as root

Re: [PULL REQUEST FOR NEXT PATCH 00/26] Patches from Fujitsu for next version

On Mon, Jan 02, 2017 at 05:47:38PM +0100, David Sterba wrote: > On Fri, Dec 30, 2016 at 09:00:36AM +0800, Qu Wenruo wrote: > > Hi, please fetch the following branch for next branch: > > https://github.com/adam900710/linux.git fujitsu_for_next > > > > This branch contains most of Fujitsu unmerged

Re: [RFC] btrfs: make max inline data can be equal to sectorsize

On Sat, Nov 19, 2016 at 03:27:02AM -0500, Zygo Blaxell wrote: > On Fri, Nov 18, 2016 at 03:58:06PM -0500, Chris Mason wrote: > > > > > > On 11/16/2016 11:10 AM, David Sterba wrote: > > >On Mon, Nov 14, 2016 at 09:55:34AM +0800, Qu Wenruo wrote: > > >>At 11/12/2016 04:22 AM, Liu Bo wrote: > >

Re: [PULL REQUEST FOR NEXT PATCH 00/26] Patches from Fujitsu for next version

On Fri, Dec 30, 2016 at 09:00:36AM +0800, Qu Wenruo wrote: > Hi, please fetch the following branch for next branch: > https://github.com/adam900710/linux.git fujitsu_for_next > > This branch contains most of Fujitsu unmerged patches for for-next branch. > > Latest David's for-next-20161219

Re: [PATCH] btrfs-progs: Get the highest inode for lost+found

On Fri, Dec 23, 2016 at 09:08:32AM +0800, Qu Wenruo wrote: > >>> Signed-off-by: Goldwyn Rodrigues > Reviewed-by: Qu Wenruo Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

Re: [PATCH] btrfs: Replace ACCESS_ONCE with (READ|WRITE)_ONCE

On Mon, Dec 26, 2016 at 01:08:09PM +0200, Nikolay Borisov wrote: > Use the newer and standardized functions when performing volatile > accesses. Following text is taken from 4d3199e4ca8e > ("locking: Remove ACCESS_ONCE() usage") : > > ACCESS_ONCE() does not work reliably on non-scalar types.

Re: [PATCH] Btrfs: Fix deadlock between direct IO and fast fsync

On Fri, Dec 23, 2016 at 04:18:00PM -0800, Liu Bo wrote: > > > Btw, I was able to reproduce the issue on kdave/for-next branch with > > > "Merge > > > branch 'for-next-next-4.9-20161125' into for-next-20161125" as the topmost > > > commit. The issue cannot be reproduced yet on latest code

Re: [markfasheh/duperemove] Why blocksize is limit to 1MB?

> 1M is already a little bit too big in size. Not in my usecase :) Is it right the this isn't an limit in btrfs? So i can patch this and try 100M. The reason is, that i must dedupe the whole 8 TB in less then a day but with 128K and 1M blocksize it will take a week. I don't know why adding

Will fstrim discard unused parts of chunks?

I try to understand what exactly is trimmed in case of btrfs. Using installation in QEMU I see that host file size is about 9GB, allocated size in guest approximately matches it and used space in guest is 7.6GB. After some experimenting it looks like host size follows "Device allocated" value in