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.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 BBDC1C28CBC for ; Sun, 3 May 2020 06:05:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 96D482073E for ; Sun, 3 May 2020 06:05:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=colorremedies-com.20150623.gappssmtp.com header.i=@colorremedies-com.20150623.gappssmtp.com header.b="JeDEX5FH" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726942AbgECGF3 (ORCPT ); Sun, 3 May 2020 02:05:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33698 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726906AbgECGF2 (ORCPT ); Sun, 3 May 2020 02:05:28 -0400 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 84F17C061A0C for ; Sat, 2 May 2020 23:05:27 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id x17so16912149wrt.5 for ; Sat, 02 May 2020 23:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=colorremedies-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WVf59aC75v/6hCO+qKHmZhC4VJfVWO0I5ZKyzvy2xjQ=; b=JeDEX5FHPoNu0nFVlt3Cug5itx0OpL3UKUgvsDoZPz9Lamg0s4YeI74Qm6bH/Zzllo GqOHzi9O85e90WtZKNxzB+kXXUxKF4SWqub+7Lo2pi5knNXNCaQsnUhDJnNWiyQxKmwB TR2SlXffzj2sTqWo5shEJHPhdUMs1Bpt/NQ4IlR0v+v6jVU0tdjjEcDjnIhOC5FxGtfv fboEBxj6HnbcAC/AmhXrMsi4RVWH0D2Vv1pahmzWPuE9Y6x7cT9nzsRyehtMDohMdMfF QXXo+y7mkuBIv+dcHJHo7EZ8x1VBWmmlj6YEe5QGr++pkEh+ZSN3eRgk4KpGaU/SMjYJ a1zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WVf59aC75v/6hCO+qKHmZhC4VJfVWO0I5ZKyzvy2xjQ=; b=B0rpkzkR2M5uf9UGVqPCbllj49OnIFeYrLiIRknho9YFfMiLk6Wsphcr03SQt3O7G+ C6hG1d5vewmRGbwCz0GSdHdjt0okFZosElGVDYOCuqmwM4e6Yps7Gi90Ai116FKi4dc6 +rU4UFHyN5oQhPJZ9kT+1BYSrkj8uBDa1CSajFp3jCWWFcnjFHe8LWPcrYZRWlZeoFr8 KQhSv2xYWACka5oPWb8eE8GxKSp9j+kk4TrcENBusIGZcmwPHumTuC+B/pnhcT3wL1wF Tjw/hyZ+LWQlnto90YR2tN8CPQgRDkxG2FU3J4gunoEjoNrUQnlSFcqHKnP+AOvGEy9g BNEg== X-Gm-Message-State: AGi0PuZjrvFgj98zk8V4oX+aTwQl5CAfZp57WFmSyQNazUs6cyfoHKsz Y5eDFIw5lflevpdM8RJ0yOFqxfe9bsi3e5syf52/hOOuQY8= X-Google-Smtp-Source: APiQypIq3XMWa9/9ruZVVuS9BaU2iaemU6i5rrBhXsv/1uWZUwSk62WSkpVdXFxmc+cmGfNFlQhHmScmcWRQ1n3HVGc= X-Received: by 2002:adf:e702:: with SMTP id c2mr12846226wrm.252.1588485926248; Sat, 02 May 2020 23:05:26 -0700 (PDT) MIME-Version: 1.0 References: <20200502033509.GG10769@hungrycats.org> <20200502060038.GK10769@hungrycats.org> <20200502074237.GM10769@hungrycats.org> <20200502090946.GO10769@hungrycats.org> <20200503052637.GE10796@hungrycats.org> In-Reply-To: From: Chris Murphy Date: Sun, 3 May 2020 00:05:10 -0600 Message-ID: Subject: Re: Extremely slow device removals To: Chris Murphy Cc: Zygo Blaxell , Phil Karn , Paul Jones , "linux-btrfs@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Sat, May 2, 2020 at 11:39 PM Chris Murphy wrote: > > On Sat, May 2, 2020 at 11:26 PM Zygo Blaxell > wrote: > > > > On Sat, May 02, 2020 at 11:48:18AM -0600, Chris Murphy wrote: > > > On Sat, May 2, 2020 at 3:09 AM Zygo Blaxell > > > wrote: > > > > > > > > On SD/MMC and below-$50 SSDs, silent data corruption is the most common > > > > failure mode. I don't think these disks are capable of detecting or > > > > reporting individual sector errors. I've never seen it happen. They > > > > either fall off the bus or they have a catastrophic failure and give > > > > an error on every single access. > > > > > > I'm still curious about the allocator to use for this device class. SD > > > Cards usually self-report rotational=0. Whereas USB sticks report > > > rotational=1. The man page seems to suggest nossd or ssd_spread. > > > > Use dup metadata on all single-disk filesystems, unless you are making > > an intentionally temporary filesystem (like a RAM disk, or a cache with > > totally expendable contents). The correct function for maximizing btrfs > > lifetime does not have "rotational" as a parameter. > > Btrfs defaults need to do the right thing. Currently it's single > metadata for mkfs, and ssd mount option when sysfs reports the device > rotational is false. This applies to eMMC and SD Cards. Whereas USB > sticks report they're rotational for whatever reason, and in that case > the default is DUP and nossd. But I don't know that rotational is the > best way of assuming an allocator. You address this in another thread: It's a bit unfortunate that btrfs's default is still to use single metadata on SSD. All I care about is detection on cheap SSDs. At least in my use cases, I'm not sure it's worth the extra writes from DUP to be able to recover from silent corruption. -- Chris Murphy