From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D2552C04A6B for ; Mon, 6 May 2019 18:39:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B0A0E20675 for ; Mon, 6 May 2019 18:39:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726517AbfEFSjZ convert rfc822-to-8bit (ORCPT ); Mon, 6 May 2019 14:39:25 -0400 Received: from smtprelay01.ispgateway.de ([80.67.18.13]:9082 "EHLO smtprelay01.ispgateway.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726277AbfEFSjZ (ORCPT ); Mon, 6 May 2019 14:39:25 -0400 Received: from [94.217.144.7] (helo=[192.168.177.20]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hNiWI-0005Dr-ON; Mon, 06 May 2019 20:39:22 +0200 From: "Hendrik Friedel" To: "Chris Murphy" Subject: Re[6]: Rough (re)start with btrfs Cc: "Chris Murphy" , "Qu Wenruo" , "Btrfs BTRFS" Date: Mon, 06 May 2019 18:39:14 +0000 Message-Id: In-Reply-To: References: Reply-To: "Hendrik Friedel" User-Agent: eM_Client/7.2.34062.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Df-Sender: aGVuZHJpa0BmcmllZGVscy5uYW1l Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Hello, >v2 is expected to become the default soon That is good to hear. >But from the sound of it Qu has enough >information to maybe track down the v1 problem and fix it, and >probably should be fixed as v1 is the default and is still supported >and will be forever. That's good to hear. >> >> For me, the question now is, whether we should chase this Bug or not. I >> encountered it three times while filling a 8TB drive with 7TB. Now, I >> have 1TB left and I am not sure I can reproduce, but I can try. > >I don't think it's necessary unless Qu specifically asks. Let me know Qu. >>you wouldn't want to constantly dump >that amount of information into kernel message buffer and then burden >the system logger with quite a lot of extraneous information. I understand. Still, a a pitty. >Once you have a reproducer, then you can change the scheduler and see >if your reproduce steps still reproduce the problem. I will try and let you know. It's not persistent. Greetings, Hendrik >