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 E1569138346 for ; Mon, 6 Jan 2020 14:45:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 48733E099E; Mon, 6 Jan 2020 14:45:18 +0000 (UTC) Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) (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 BBD48E0973 for ; Mon, 6 Jan 2020 14:45:17 +0000 (UTC) Received: by mail-pg1-f193.google.com with SMTP id a33so26980601pgm.5 for ; Mon, 06 Jan 2020 06:45:17 -0800 (PST) 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=VDK71BXQRcN+/g66ynPWSZpTyBf6uQ84gX8jB/0/taI=; b=V+8cB2Pv7VPuAlk/XFmltEyhIn1Js5yjiy5iNjcyZjU6/z3rwtBPI65ImWYCh0jYXV xTC3Kb/g3JUngdbUd5+eN6F5HR5FFoPl7GRdaYrpii2tQw4TVZHUZLoWmGE8pN4CvrMu sgMcW/4gqJTOoQjwjjzdeTPzyB1JdaufXiDf2qwDg1ytp7of125xcgCBdYP2oEGV4pra V5OP72Y2kSS7x6jGtHBxrYm2zicM3SzjVnIebNICruHKC/yjRklj2jrRfodjQNFzMCjK k5JEAPA0GiRu78lb+cSwxh3+Um809d0njFjv3vig16hW97WlmrFC0W9F+2UjtKgFP7PB mtTQ== X-Gm-Message-State: APjAAAVN99i3kUHe2xbRPtHhN5WGrIGOp+ooXDAZsMGef6LBycefqQ9C LGSNVFU+vkA7skxV3oiDpj5Nb39/4FeGlfKzThqb3BdD X-Google-Smtp-Source: APXvYqxHiEvivrEios80uYiELk92azzwFi1YjgkVpDJhVqN1ZjeR97EB40MB90fe+jcWaLgT5g9spamwqUYKmpUbH88= X-Received: by 2002:a63:3dc6:: with SMTP id k189mr109056878pga.396.1578321916049; Mon, 06 Jan 2020 06:45:16 -0800 (PST) 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: <1031326330.20200106094813@xss.de> <2555592.MOrcY8rQEj@dell_xps> In-Reply-To: From: Rich Freeman Date: Mon, 6 Jan 2020 09:45:04 -0500 Message-ID: Subject: Re: [gentoo-user] External hard drive and idle activity To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 5ddfa47c-15f2-4b1f-a298-e88cdf9f7388 X-Archives-Hash: 8047ca867a97ca09aa149eea156271a6 On Mon, Jan 6, 2020 at 9:18 AM Dale wrote: > > Rich Freeman wrote: > > On Mon, Jan 6, 2020 at 8:25 AM Mick wrote: > >> If they are used as normal PC drives for regular writing > >> of data, or with back up commands which use rsync, cp, etc. then the disk will > >> fail much sooner than expected because of repeated multiple areas being > >> deleted, before each smaller write. I recall reading about how short the life > >> of SMR drives was shown to be when used in NAS devices - check google or > >> youtube if you're interested in the specifics. > > Can you give a link - I'm not finding anything, and I'm a bit dubious > > of this claim, because they still are just hard drives. These aren't > > SSDs and hard drives should not have any kind of erasure limit. > > > > Now, an SMR used for random writes is going to be a REALLY busy drive, > > so I could see the drive being subject to a lot more wear and tear. > > I'm just not aware of any kind of serious study. And of course any > > particular model of hard drive can have reliability issues (just look > > up the various reliability studies). > > > > I ran up on this article however, it is a short time frame. Still might > be a interesting read tho. > > https://blogs.dropbox.com/tech/2019/07/smr-what-we-learned-in-our-first-year/ That article makes no mention of reliability issues with SMR. In fact, they mention that they want 40% of their storage to be on SMR by now. Clearly they wouldn't be doing that if the drives failed frequently. Note that they did modify their software to have write patterns suitable for SMR. That is the key here. You absolutely have to engineer your application to be suitable for SMR, or only choose SMR if your application is already suitable. You can't just expect these drives to perform remotely acceptably if you just throw random writes at them. > I'm still a bit curious and somewhat untrusting of those things tho. > Regular hard drives go bad often enough as it is. We don't need some > fancy unknown thing inserted just to add more issues. Sort of reminds > me of the init thingy. Each thing added is another failure point. Obviously they're relatively new, but they seem reliable enough. They're just not suitable for general purpose use. > I'm going to test my ebay skills and see if I can find some non-SMR > drives. It sounds like some require some research to know if they are > or not. :/ That's pretty simple. Find a drive that looks reasonable price/capacity/etc-wise. Then just google the model number to confirm it isn't SMR. If you're in the US though you're probably best off shucking drives from Best Buy these days. A drive that costs $350 as a bare drive will get sold for $180 in a USB enclosure. I think it is just market segmentation. They want to get top dollar from enterprise users, and they aren't going to be shucking drives from Best Buy bought on "limit 1 item per customer" sales. By shucking I'm getting 12TB red drives for less than the cost of a 6TB green drive. Just be aware that if your PSU is old you'll need to tape over some of the SATA power pins. New PSUs - even cheap ones - haven't given me any trouble. I'm sure there are more up-to-date guides as these days the drives are 12TB, but here is the gist of it: https://www.reddit.com/r/DataHoarder/comments/7fx0i0/wd_easystore_8tb_compendium/ If you aren't in the US I have no idea whether equivalent deals are available. That subreddit is a good place to go for info on cheap hard drives though. -- Rich