From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B8B11138350 for ; Sun, 3 May 2020 20:16:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 935FEE09D6; Sun, 3 May 2020 20:16:21 +0000 (UTC) Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 094FBE0993 for ; Sun, 3 May 2020 20:16:20 +0000 (UTC) Received: by mail-ej1-f42.google.com with SMTP id e2so12101072eje.13 for ; Sun, 03 May 2020 13:16:20 -0700 (PDT) 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; bh=D5SrF8YgULD4rPFyiSa14rKWr/B9Vz2deipseN6XOUI=; b=hDdB4nZutxqc49QlzMGZfh/Po+4FrDuHJ4VpA9qvb/aoBs8jnivHYrH7gwb1KDS2RM W10hR4aEup8JMp/2iwS3ZBYbJlLH9bmAnPrUFHRnJ4QB7rFMHV5DvcbAjk7jp4XQ7X1V LWB3CIEzosEdon78FyX8uNQMqHXYsf9/LR9EexHyVcdUy2Kpj5J3MFBjgkrLHWZIOcUa WesTZX9QVXPj0MLvE/w3Yv2HRSvprfrSlUUWPXcolC5whIp2+QlhuqkzEkxwJkEsCnw7 tctgNZNb1xo42mmwhlyZw8iA5Tw5xQBRMV3WFNIhyPQDAa8PxPwgKskskuFeu76JJrY7 4aAg== X-Gm-Message-State: AGi0PuY9TC5fDxZYROrksWv3DWdOXJz6TkSO5rKpmXE2MyvMjbRhMbsy URiFlT/MuIs2zHK03EOPVn52O21M8gHbYOl3zkLU/Arr X-Google-Smtp-Source: APiQypJuzgh0+f4DPwLaKW+8/uJB4TedlSdOb01BUEN7UDyCH0rLbKl1GJnh5eLj24sFIbBRkYkaksc2EuSA71wQo3M= X-Received: by 2002:a17:906:3296:: with SMTP id 22mr12576086ejw.195.1588536979394; Sun, 03 May 2020 13:16:19 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <1821f420-8977-0d91-b0f9-9d41b12d11ae@konstantinhansen.de> <5EAE8DA1.8020105@youngman.org.uk> In-Reply-To: From: Rich Freeman Date: Sun, 3 May 2020 16:16:08 -0400 Message-ID: Subject: Re: [gentoo-user] which linux RAID setup to choose? To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 5635dc9f-a4bd-4b17-81e5-97239cae72d0 X-Archives-Hash: d09df5aff8c4ad859226988aa0a5f4d8 On Sun, May 3, 2020 at 2:29 PM Mark Knecht wrote: > > I've used the WD Reds and WD Golds (no not sold) and never had any problem. > Up until a few weeks ago I would have advised the same, but WD was just caught shipping unadvertised SMR in WD Red disks. This is going to at the very least impact your performance if you do a lot of writes, and it can be incompatible with rebuilds in particular with some RAID implementations. Seagate and Toshiba have also been quietly using it but not in their NAS-labeled drives and not as extensively in general. At the very least you should check the model number lists that have been recently released to check if the drive you want to get uses SMR. I'd also get it from someplace with a generous return policy and do some benchmarking to confirm that the drive isn't SMR (you're probably going to have to do continuous random writes exceeding the total capacity of the drive before you see problems - or at least quite a bit of random writing - the amount of writing needed will be less once the drive has been in use for a while but a fresh drive basically acts like close to a full-disk-sized write cache as far as SMR goes). > Build a RAID with a WD Green and you're in for trouble. ;-))) It really depends on your RAID implementation. Certainly I agree that it is better to have TLER, but for some RAID implementations not having it just causes performance drops when you actually have errors (which should be very rare). For others it can cause drives to be dropped. I wouldn't hesitate to use greens in an mdadm or zfs array with default options, but with something like hardware RAID I'd be more careful. If you use aggressive timeouts on your RAID then the Green is more likely to get kicked out. I agree with the general sentiment to have a spare if it will take you a long time to replace failed drives. Alternatively you can have additional redundancy, or use a RAID alternative that basically treats all free space as an effective spare (like many distributed filesystems). -- Rich