>
> 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
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
Tr
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 filesystem
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 don't
>>> understand where you see conflict?
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 done a lot during
> the test
__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 292c94c45df0..75128bd23140 10
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 bu
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 y
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 filesyste
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 change follows the change to automatically remove qgro
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 -
> -
> 1 file chang
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 non-existent subvolume?
>> It looks l
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 enough
> >>> pinned byte
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
> anyway).
If you can acq
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
> > guess (then again I do
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 wrote:
This change follows the change to automatic
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 a level 0 qgroup for a no
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
>> > fsck repair to run, is going to be dif
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 4.9.13-
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.
*/
WARN_ON(send_root->orphan_c
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 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:
Totally
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 qgr
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
Hi Timofey,
[auto build test ERROR on v4.9-rc8]
[also build test ERROR on 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/Timofey-Titovets/Btrfs-lzo-c
Hi Sargun,
[auto build test WARNING on linus/master]
[also build test WARNING 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
26 matches
Mail list logo
