linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Hendrik Friedel <hendrik@friedels.name>,
	Tomasz Kusmierz <tom.kusmierz@gmail.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>, dave@jikos.cz
Subject: Re: Status of SMR with BTRFS
Date: Mon, 18 Jul 2016 15:30:57 -0400	[thread overview]
Message-ID: <aa570d41-872d-bfde-e569-85e8b274b029@gmail.com> (raw)
In-Reply-To: <f7dec129-0aa2-832a-1842-95cd2ddd940e@friedels.name>

On 2016-07-18 15:05, Hendrik Friedel wrote:
> Hello Austin,
>
> thanks for your reply.
>
>>> Ok, thanks; So, TGMR does not say whether or not the Device is SMR or
>>> not, right?
>> I'm not 100% certain about that.  Technically, the only non-firmware
>> difference is in the read head and the tracking.  If it were me, I'd be
>> listing SMR instead of TGMR on the data sheet, but I'd be more than
>> willing to bet that many drive manufacturers won't think like that.
>>> While the Data-Sheet does not mention SMR and the 'Desktop' in the name
>>> rather than 'Archive' would indicate no SMR, some reviews indicate SMR
>>> (http://www.legitreviews.com/seagate-barracuda-st5000dm000-5tb-desktop-hard-drive-review_161241)
>>>
>>>
>>  Beyond that, I'm not sure,
>> but I believe that their 'Desktop' branding still means it's TGMR and
>> not SMR.
>
> ... which in the Seagate nomenclature might not exclude each other (TGMR
> could still be SMR). I will just ask them...
> How did you find out on your drives whether they use SMR?
I've actually manually deconstructed quite a few hard disks for work. 
We have to wipe old disks before they leave the building, and if we 
can't do it in software because of something like a head crash, we have 
to take them apart and physically destroy the platters.  There are 
actually visible differences in regular TGMR and SMR heads, so if you 
know what to look for, you can tell by the write heads (it's also a dead 
giveaway when a drive has significantly fewer platters than TB's of 
space).  There's also measurable performance differences for certain 
access patterns, but that doesn't work as reliably as it sounds like it 
should (the actual physical data layout on disk these days may look 
nothing like what software sees).
>
>> I'd very much suggest avoiding USB connected SMR drives though, USB is
>> already poorly designed for storage devices (even with USB attached
>> SCSI), and most of the filesystem issues I see personally (not just with
>> BTRFS, but any other filesystem as well) are on USB connected storage,
>> so I'd be very wary of adding all the potential issues with SMR drives
>> on top of that as well.
>
> Understood. But I use this drive as a Backup. The Drive must not be
> connected to the System unless doing a backup. Otherwise a Virus, or
> just an issue with the power (peak due to lightning strike) might vanish
> both the Source data and Backup at once (single point of failure).
In that case, I'd be very careful to wait for a while after finishing a 
backup before disconnecting the disk (and make sure to unmount the 
filesystem before waiting so that everything gets flushed to disk), and 
make sure to validate your backups as well.  Once the disk has been 
safely disconnected, you're fine though, the issues arise if the device 
suddenly disappears from the bus or loses power (which is of course an 
issue for regular drives, the filesystem damage just tends to be much 
worse with SMR drives).  For what it's worth, I've seen fewer issues 
with (recent) USB 3.0 devices than USB 2.0, but even just bumping the 
cable can cause issues sometimes.

  reply	other threads:[~2016-07-18 19:31 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-15 18:29 Status of SMR with BTRFS Hendrik Friedel
2016-07-15 22:15 ` Tomasz Kusmierz
2016-07-16 10:29   ` Hendrik Friedel
2016-07-17  3:09     ` Tomasz Kusmierz
2016-07-17  9:08       ` Hendrik Friedel
2016-07-17 20:48         ` Henk Slager
2016-07-18 11:22         ` Austin S. Hemmelgarn
2016-07-18 18:31           ` Hendrik Friedel
2016-07-18 18:44             ` Austin S. Hemmelgarn
2016-07-18 19:05               ` Hendrik Friedel
2016-07-18 19:30                 ` Austin S. Hemmelgarn [this message]
2016-07-18 22:29                   ` Tomasz Kusmierz
2016-07-20 19:58         ` Chris Murphy
2016-07-21 12:46           ` Austin S. Hemmelgarn
2016-07-21 13:34             ` Chris Murphy
2016-07-21 14:02               ` Andrei Borzenkov
2016-07-21 14:12               ` Austin S. Hemmelgarn
2016-07-21 14:31                 ` Chris Murphy
2016-07-21 15:35               ` Patrik Lundquist
  -- strict thread matches above, loose matches on Subject: below --
2016-07-17  8:26 Matthias Prager
2016-07-17 20:10 ` Henk Slager
2016-07-17 21:44   ` Matthias Prager
2016-07-18 18:49     ` Jukka Larja
2016-07-21 12:22 Matthias Prager

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=aa570d41-872d-bfde-e569-85e8b274b029@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=dave@jikos.cz \
    --cc=hendrik@friedels.name \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=tom.kusmierz@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).