Re: Status of SMR with BTRFS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux