Patchset can be fetched from github:
https://github.com/adam900710/btrfs-progs.git dedupe_20170523
Inband dedupe(in-memory backend only) ioctl support for btrfs-progs.
Existing tester/reviewer can just rebase v10 patches to btrfs-progs v4.11 tags.
All conflicts can be resolved by git without any
Just some user's point of view:
I propose the following changes:
1) We always cleanup level-0 qgroups by default, with no opt-out.
I see absolutely no reason to keep these around.
It WILL break scripts that try to do this cleanup themselves. OTOH it
will simplify writing new ones.
Since
This patchset can be fetched from github:
https://github.com/adam900710/linux.git wang_dedupe_latest
This is just a normal rebase update.
Now the new base is v4.12-rc1.
Normal test cases from auto group exposes no regression, and ib-dedupe
group can pass without problem.
Changelog:
v2:
Hi Sargun,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc2 next-20170522]
[cannot apply to btrfs/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Sargun-Dhillon
This is probably not a bug I should report and simply an issue with the
filesystem I'm trying to get data out of, but reporting it just in case
it's useful somehow.
/*
* This is done when we lookup the root, it should already be complete
* by the time we get here.
*/
At 03/16/2017 08:23 PM, 李云甫 wrote:
hi, buddy
I have a file server with btrfs file system, it's work well for several
months.
but after last system reboot, the /dev/sdb become not mountable.
below is the details. is there any advise?
##Version info
Fedora 25 Server
Kernel
On Mon, May 22, 2017 at 5:57 PM, Marc MERLIN wrote:
> On Mon, May 22, 2017 at 05:26:25PM -0600, Chris Murphy wrote:
>> On Mon, May 22, 2017 at 10:31 AM, Marc MERLIN wrote:
>>
>> >
>> > I already have 24GB of RAM in that machine, adding more for the real
>> >
At 05/23/2017 04:54 AM, Sargun Dhillon wrote:
On Sun, May 21, 2017 at 5:59 PM, Qu Wenruo wrote:
At 05/19/2017 05:07 PM, Sargun Dhillon wrote:
I have some questions about the *intended* qgroups semantics, and why
we allow certain operations:
1) Why can you create
At 05/23/2017 01:31 AM, Sargun Dhillon wrote:
On Sun, May 21, 2017 at 7:03 PM, Qu Wenruo wrote:
At 05/22/2017 09:58 AM, Sargun Dhillon wrote:
On Sun, May 21, 2017 at 6:20 PM, Qu Wenruo
wrote:
At 05/20/2017 04:39 PM, Sargun Dhillon
On Mon, May 22, 2017 at 05:26:25PM -0600, Chris Murphy wrote:
> On Mon, May 22, 2017 at 10:31 AM, Marc MERLIN wrote:
>
> >
> > I already have 24GB of RAM in that machine, adding more for the real
> > fsck repair to run, is going to be difficult and ndb would take days I
> >
On Mon, May 22, 2017 at 10:31 AM, Marc MERLIN wrote:
>
> I already have 24GB of RAM in that machine, adding more for the real
> fsck repair to run, is going to be difficult and ndb would take days I
> guess (then again I don't have a machine with 32 or 48 or 64GB of RAM
>
On Sun, May 21, 2017 at 03:45:02PM +0300, Nikolay Borisov wrote:
>
>
> On 19.05.2017 21:32, Liu Bo wrote:
> > On Fri, May 19, 2017 at 12:54:59PM +0300, Nikolay Borisov wrote:
> >>> From: Liu Bo
> >>>
> >>> Subject: [PATCH] Btrfs: skip commit transaction if we don't have
On Sun, May 21, 2017 at 5:59 PM, Qu Wenruo wrote:
>
>
> At 05/19/2017 05:07 PM, Sargun Dhillon wrote:
>>
>> I have some questions about the *intended* qgroups semantics, and why
>> we allow certain operations:
>>
>> 1) Why can you create a level 0 qgroup for a
On Thu, 2017-05-18 at 15:18 +0200, Christoph Hellwig wrote:
> This simplifies the code and especially the error passing a bit and
> will help with the next patch.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/md/dm-mpath.c | 42 -
> -
>
On Sun, May 21, 2017 at 7:03 PM, Qu Wenruo wrote:
>
>
> At 05/22/2017 09:58 AM, Sargun Dhillon wrote:
>>
>> On Sun, May 21, 2017 at 6:20 PM, Qu Wenruo
>> wrote:
>>>
>>>
>>>
>>> At 05/20/2017 04:39 PM, Sargun Dhillon wrote:
This
On Sun, May 21, 2017 at 06:35:53PM -0700, Marc MERLIN wrote:
> On Sun, May 21, 2017 at 04:45:57PM -0700, Marc MERLIN wrote:
> > On Sun, May 21, 2017 at 02:47:33PM -0700, Marc MERLIN wrote:
> > > gargamel:~# btrfs check --repair /dev/mapper/dshelf1
> > > enabling repair mode
> > > Checking
On Thu, 18 May 2017, Peter Becker wrote:
> I'm not sure if this would be helpfull but can you post the output
> from this script?
> cd /tmp
> wget https://raw.githubusercontent.com/kdave/btrfs-progs/master/btrfs-debugfs
> chmod +x btrfs-debugfs
> stats=$(sudo ./btrfs-debugfs -b /)
> ...
Thank
Commit 5f39d397dfbe ("Btrfs: Create extent_buffer interface
for large blocksizes") refactored btrfs_leaf_data function to take
extent_buffer rather than struct btrfs_leaf. However, as it turns out the
parameter being passed is never used. Furthermore this function no longer
returns the leaf data
__BTRFS_LAF_DATA_SIZE is used only by BTRFS_LEAF_DATA_SIZE. Make the latter
subsume the former.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.h | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index
Okay sure, When I find free-time, will run few more combinations and
let you know the details along with any other suggestions/thoughts on
the interface. thanks.
On 5/22/17, Qu Wenruo wrote:
> Good to hear that.
>
> And you could try more combination (although I have
Timofey Titovets posted on Mon, 22 May 2017 01:32:21 +0300 as excerpted:
> 2017-05-21 20:30 GMT+03:00 Roman Mamedov :
>> On Sun, 21 May 2017 19:54:05 +0300 Timofey Titovets
>> wrote:
>>
>>> Sorry, but i know about subpagesize-blocksize patch set, but i
Marc MERLIN posted on Sun, 21 May 2017 18:35:53 -0700 as excerpted:
> On Sun, May 21, 2017 at 04:45:57PM -0700, Marc MERLIN wrote:
>> On Sun, May 21, 2017 at 02:47:33PM -0700, Marc MERLIN wrote:
>> > gargamel:~# btrfs check --repair /dev/mapper/dshelf1 enabling repair
>> > mode Checking
Yes. It detects the injected corruption.
#btrfs scrub start --offline /dev/loop6
ERROR: data at bytenr 145293312 mirror 0 csum mismatch, have
0x790f1fe1 expect 0xa30cb5c5
ERROR: full stripe 145227776 RECOVERABLE: Data stripes corrupted, but
P/Q is good
Scrub result:
Tree bytes scrubbed: 131072
>
> As the title said, it's *offline* scrub, while you're still using the
> *online* scrub.
>
> To use offline scrub, you should exec "btrfs scrub start --offline
> "
>
> And then it should detect the same error.
> Output is nothing like kernel.
>
> Thanks,
> Qu
>
Ah,my bad. I thought the entire
Following the factoring out of the creation code udpate_space_info can only
be called for already-existing space_info structs. As such it cannot fail.
Remove superfulous error handling and make the function return void.
Signed-off-by: Nikolay Borisov
Reviewed-by: Jeff Mahoney
Currently the struct space_info creation code is intermixed in the
udpate_space_info function. There are well-defined points at which the we
actually want to create brand-new space_info structs (e.g. during mount of
the filesystem as well as sometimes when adding/initialising new chunks). In
such
When I ran the script, it produces below output. From the output it
looks like, it detected the error and corrected. But parity-block
corruption fix patch not yet merged or I missed something?
Run: (with scrub_offline repo)
btrfs scrub start /home/laks/centos/laks/BTRFS/scrub_offline/tests/mnt
27 matches
Mail list logo