From: "Sid Spry" <sid@aeam.us>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Testing a used hard drive to make SURE it is good.
Date: Tue, 23 Jun 2020 11:14:03 -0500 [thread overview]
Message-ID: <4f35306e-e509-4cae-907d-7eb026c008e9@www.fastmail.com> (raw)
In-Reply-To: <CAGfcS_nbOMtuN9kjYmBQ_A-h-PwG3iaMvNtBmJuAv5uF0YvwrQ@mail.gmail.com>
On Tue, Jun 16, 2020, at 7:25 AM, Rich Freeman wrote:
> On Tue, Jun 16, 2020 at 7:36 AM Michael <confabulate@kintzios.com> wrote:
> >
> > Just to add my 2c's before you throw that SMR away, the use case for these
> > drives is to act as disk archives, rather than regular backups. You write
> > data you want to keep, once.
>
> If your write pattern is more like a tape SMR should be ok in theory.
> For example, if you wrote to a raw partition using tar (without a
> filesystem) I suspect most SMR implementations (including
> drive-managed) would work tolerably (a host-managed implementation
> would perform identically to CMR). Once you toss in a filesystem then
> there is no guarantee that the writes will end up being sequential.
>
> And of course the problem with these latest hidden SMR drives is that
> they generally don't support TRIM, so even repeated sequential writes
> can be a problem because the drive doesn't realize that after you send
> block 1 you're going to send blocks 2-100k all sequentially. If it
> knew that then it would just start overwriting in place obliterating
> later tracks, since they're just going to be written next anyway.
> Instead this drive is going to cache every write until it can
> consolidate them, which isn't terrible but it still turns every seek
> into three (write buffer, read buffer, write permanent - plus updating
> metadata). If they weren't being sneaky they could have made it
> drive-managed WITH TRIM so that it worked more like an SSD where you
> get the best performance if the OS uses TRIM, but it can fall back if
> you don't. Sequential writes on trimmed areas for SMR should perform
> identically to writes on CMR drives.
>
So if I'm understanding properly most drive firmware won't let you
operate the device in an append-only mode? If any do I suspect
NILFS (https://en.wikipedia.org/wiki/NILFS) may be a good choice:
"NILFS is a log-structured filesystem, in that the storage medium is treated
like a circular buffer and new blocks are always written to the end. [...]"
Realistically I don't know how maintained the filesystem is, and it may
still enforce a hot and warm/cold data separation as a practical concern.
As-is my intended use for these very large drives was not going to be for
hot files anyway; spinning media is too slow. They were going to be running
a snapshottable filesystem and would host my backups.
But if I'm reading it right these drives just suck across the board? I'm
confused. It's like they'd be good at one thing but then they tried to
lie behind the scenes and ended up making the drives good at nothing.
next prev parent reply other threads:[~2020-06-23 16:14 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-15 16:07 [gentoo-user] Testing a used hard drive to make SURE it is good Dale
2020-06-15 19:20 ` Spackman, Chris
2020-06-15 19:54 ` Mark Knecht
2020-06-15 20:00 ` Rich Freeman
2020-06-15 20:04 ` Mark Knecht
2020-06-16 7:34 ` Dale
2020-06-16 8:22 ` Wols Lists
2020-06-16 9:04 ` Dale
2020-06-16 11:02 ` Wols Lists
2020-06-16 11:26 ` Dale
2020-06-16 11:36 ` Michael
2020-06-16 12:25 ` Rich Freeman
2020-06-16 23:38 ` antlists
2020-06-17 9:47 ` Rich Freeman
2020-06-23 16:14 ` Sid Spry [this message]
2020-06-23 17:20 ` Rich Freeman
2020-06-23 18:44 ` Sid Spry
2020-06-16 13:14 ` Dale
2020-06-16 23:24 ` antlists
2020-06-17 4:47 ` Dale
2020-06-17 12:32 ` Wols Lists
2020-06-17 12:04 ` Rich Freeman
2020-06-16 8:29 ` Neil Bothwick
2020-06-16 8:52 ` Dale
2020-06-15 19:54 ` [gentoo-user] " Grant Edwards
2020-06-15 20:04 ` Grant Edwards
2020-06-15 23:03 ` [gentoo-user] " madscientistatlarge
2020-06-15 23:18 ` David Haller
2020-06-16 7:17 ` Dale
2020-06-16 7:32 ` William Kenworthy
2020-06-16 7:37 ` Dale
2020-06-17 15:27 ` David Haller
2020-06-18 8:07 ` Dr Rainer Woitok
2020-06-23 16:08 ` Sid Spry
2020-06-23 16:38 ` [gentoo-user] " Grant Edwards
2020-06-23 16:41 ` Sid Spry
2020-06-23 17:26 ` Dale
2020-06-23 18:32 ` Sid Spry
2020-06-23 19:37 ` Dale
2020-06-23 20:03 ` Rich Freeman
2020-06-24 4:26 ` Wols Lists
2020-06-18 9:14 ` [gentoo-user] " Dale
2020-06-22 1:52 ` Pengcheng Xu
2020-06-22 2:15 ` Dale
2020-06-22 19:10 ` David Haller
2020-06-22 20:29 ` Dale
2020-06-22 22:59 ` David Haller
2020-06-23 4:18 ` Dale
2020-06-17 6:02 ` Dale
2020-06-20 9:50 ` Dale
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4f35306e-e509-4cae-907d-7eb026c008e9@www.fastmail.com \
--to=sid@aeam.us \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox