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 7D656C28CBC for ; Sun, 3 May 2020 05:40:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4219920752 for ; Sun, 3 May 2020 05:40:08 +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="btKsRzB0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726904AbgECFjj (ORCPT ); Sun, 3 May 2020 01:39:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57914 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726884AbgECFji (ORCPT ); Sun, 3 May 2020 01:39:38 -0400 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74EF0C061A0C for ; Sat, 2 May 2020 22:39:38 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id v4so12854800wme.1 for ; Sat, 02 May 2020 22:39:38 -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=5NLUHJ42u/wUdyFZ3vBwH4RBaGWjuw40+XwTreczlvc=; b=btKsRzB0QK61m2y4Cyp6aFd2wNKkOkelPVs7dNE8m3R0uojLJ0HsKbC03c8vAfthpN rre74XcaScfPW7Vo8K1kunfd2sUPuG6B+0zlctLoiK+Dh4HLUFio0rN4A6tyTHxHkUdy bXiUEtNTzMVqt5jNaK+eUVSTUokPX341y7krTijgLHi4SN8RwD8R+/nTsUzB6KHcviKT BlnW0OX9/6NBerACDr4u8kEpNyaSqK6N8vGVzAyHOZm6yoaqnRwZ023hf3v9cKbT18Cb idKfbhWqBgyipgoSeqXTlc/FAcNPSYLcyaFip79KOiZqr7nwcksgicdfck2AcRa4IVds r5bg== 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=5NLUHJ42u/wUdyFZ3vBwH4RBaGWjuw40+XwTreczlvc=; b=oPoBbiffqpiopMRf8KPAoI8YeOBe5ck+Kv23206lEbgJrEWiRIiEB8yqCU9POWv/Cb iatCPzRfMMBWxXVhETXgLePso17CWoPB3n3VDDbdQOlaUADaSmGoOeOMKL7QTJl7QoFb e1W23Jms+VMOuoSDMFsI8P7//whRANjWi5K2ttRssk46FgWYaUlaz0ljWkxY5IBRg+Vd gq70qXpqFiaBvPocBBiJODubzPjRlNDKwoM0kJQF5LBvXPtq9/QxtK22gBTOQYQnffkw Xj6O/Cv9ZmEJYlbcuQgHtaQJr5AP7obPXxx40nDcjCDXVRn3kdH2SxsP2yCKIXD0+UgK 1p2Q== X-Gm-Message-State: AGi0PuaXDkYnlwZnYNYHx0dv61qT/TsDBR4z1SygjbaLCVA6HL015Dnd vYauSBj+AvQQdT8cA3RK6U+3zZZTdXTCc0Mt6UgZzjOx X-Google-Smtp-Source: APiQypLOHikrBFkJn4XS0j3WAk2XEgfKSPnXXscz830crWy/Hs5pewvyr8/qX3/1xOM9idliF1yJSWqnFUuWRRC2OJc= X-Received: by 2002:a1c:1b0b:: with SMTP id b11mr8171687wmb.182.1588484376846; Sat, 02 May 2020 22:39:36 -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: <20200503052637.GE10796@hungrycats.org> From: Chris Murphy Date: Sat, 2 May 2020 23:39:20 -0600 Message-ID: Subject: Re: Extremely slow device removals To: Zygo Blaxell Cc: Chris Murphy , 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: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. -- Chris Murphy