Re: [gentoo-user] [OT] SMR drives (WAS: cryptsetup close and device in use when it is not)

[William Kenworthy]

On 30/7/21 4:55 am, Frank Steinmetzger wrote:
> Am Thu, Jul 29, 2021 at 05:46:16PM +0100 schrieb Wols Lists:
>
>>> Yea. First the SMR fiasco became public and then there was some other PR
>>> stunt they did that I can’t remember right now, and I said “I can’t buy WD
>>> anymore”. But there is no real alternative these days. And CMR drives are
>>> becoming ever rarer, especially in the 2.5″ realm. Except for one single
>>> seagate model, there isn’t even a bare SATA drive above 2 TB available on
>>> the market! Everything above that size is external USB stuff. And those
>>> disks don’t come with standard SATA connectors anymore, but have the USB
>>> socket soldered onto their PCB.
>>>
>> Are you talking 2.5" drives here?
> I meant in general, but – as I said – “especially in the 2.5″ realm”. ;-)
> For 3.5″, it’s mostly the low-capacity drives that are affected. Probably
> because here the ratio of fixed cost (case, electronics) vs. per-capacity
> cost (platters, heads) is higher, so the pressure to reduce manufacturing
> cost is also higher. High-capacity drives tend to remain CMR at the mo’.
>
>> The SMR stunt was a real cock-up as far as raid was concerned - they
>> moved their WD Red "ideal for raid and NAS" drives over to SMR and
>> promptly started killing raid arrays left right and centre as people
>> replaced drives ... you now need Red Pro so the advice for raid is just
>> "Avoid WD".
> Red Plus is fine, too. I think the “Plus” is marketing speak for non-SMR.
> Which is why probably SMRs now have the price tag of old CMRs, and the new
> CMRs have a “plus” on the price tag.
>
>> From what I can make out with Seagate, the old Barracuda line is pretty
>> much all CMR, they had just started making some of them SMR when the
>> brown stuff hit the rotating blades.
> Seagate made a statement that their NAS drives are not and never will be SMR.
>
>
>
> In case someone is interested, here’s a little experience report:
>
> Two days ago, I bought a 2.5″ WD My Passport 4 TB for a new off-site backup
> strategy I want to implement. They even killed the rubber feet on the
> underside to save a few cents. >:'-( ) Interestingly, the even cheaper
> elements series (which is the cheapest because it has no complimentary
> sofware and no encryption or password feature) still has them. Probably
> because its case design is older.
>
> I just finished transferring my existing Borg backup repos. Right at the
> beginning, I tested a small repo of 3 GiB and I got good throughput. After
> around 2 GiB or so the drive went down to 10 MiB/s for a very long time
> (writing at least another 3 GiB, I have no idea what that was).
>
> I was already pondering my options. But once that was over, I’ve since been
> writing 1,2 TiB to the drive with rsync happily without any glitches,
> averaging at slightly above 100 MiB/s. I used SMR-friendly ext4 settings and
> Borg uses datafiles of 500 MiB size, which greatly reduces sprinkled
> metadata writes b/c it’s only a few thousand files instead of millions.
>
> According to smartctl, the drive claims to support Trim, but so far I’ve
> been unsuccessful to invoke it with fstrim. First I had to enable the
> allow-discard option in the underlying LUKS container, which is disabled by
> default for security reasons. But either I’m still missing a detail, or the
> USB-SATA-bridge really does not support it. Or it does, but the kernel is
> unaware: yesterday I read an article about enabling a flag for the USB
> controller via a custom UDEV rule. Who knows.
>
I am using a seagate USB3 backup disk (4Tb SMR) for borgbackup on
btrfs.  Yes, it works well on regular backups, but its dismally slow 
for anything else (operations that read or write large amounts of data
at once):

1. Adding a lot of new data to a repo is extra slow

2. btrfs scrub (a couple of days)

3. borg repair (days!)

I had an unscheduled crash that lost a btrfs segment - scrub showed it
as an uncorrectable error so I deleted the file involved and borg repair
zeroed that part of the repo so its still ok. On a regular backup run
its fine, but if recovery time if you have an error is a real problem.

BillK