From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f179.google.com ([74.125.82.179]:48452 "EHLO mail-ot0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754284AbdKCWDp (ORCPT ); Fri, 3 Nov 2017 18:03:45 -0400 Received: by mail-ot0-f179.google.com with SMTP id f56so3863864otj.5 for ; Fri, 03 Nov 2017 15:03:45 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <9871a669-141b-ac64-9da6-9050bcad7640@cn.fujitsu.com> <10fb0b92-bc93-a217-0608-5284ac1a05cd@rqc.ru> From: Chris Murphy Date: Fri, 3 Nov 2017 16:03:44 -0600 Message-ID: Subject: Re: Problem with file system To: "Austin S. Hemmelgarn" Cc: Marat Khalili , Chris Murphy , Dave , Linux fs Btrfs , Fred Van Andel Content-Type: text/plain; charset="UTF-8" Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Tue, Oct 31, 2017 at 5:28 AM, Austin S. Hemmelgarn wrote: > If you're running on an SSD (or thinly provisioned storage, or something > else which supports discards) and have the 'discard' mount option enabled, > then there is no backup metadata tree (this issue was mentioned on the list > a while ago, but nobody ever replied), This is a really good point. I've been running discard mount option for some time now without problems, in a laptop with Samsung Electronics Co Ltd NVMe SSD Controller SM951/PM951. However, just trying btrfs-debug-tree -b on a specific block address for any of the backup root trees listed in the super, only the current one returns a valid result. All others fail with checksum errors. And even the good one fails with checksum errors within seconds as a new tree is created, the super updated, and Btrfs considers the old root tree disposable and subject to discard. So absolutely if I were to have a problem, probably no rollback for me. This seems to totally obviate a fundamental part of Btrfs design. because it's already been discarded. > This is ideally something which should be addressed (we need some sort of > discard queue for handling in-line discards), but it's not easy to address. Discard data extents, don't discard metadata extents? Or put them on a substantial delay. -- Chris Murphy