Live data from Hacker News

Backblaze hard drive reliability stats for Q3 2016

backblaze.com

111–116 of 116 posts

Re: Backblaze hard drive reliability stats for Q3 2016

#111
post #94

Earlier quoted context omitted.

Does "secure wipe" mean ATA SE, i.e. hdparm --security-erase, or --security-erase-enhanced?

For that volume I'd think a degausser would be used.

Degaussers render the drive nonfunctional.

Re: Backblaze hard drive reliability stats for Q3 2016

#112
post #104
post #65

Earlier quoted context omitted.

That's not entirely true. Higher density means more data per track, not just more tracks per disk. You get an entire track per revolution so a track with more data is more MBps. So linear reads on a higher density drive are faster, and semi-linear accesses (ie, reading two files that are next to each other) do get faster. I remember reading a story about a guy who built a drive array with high capacity 7200 RPM drive…

Short stroking helps get more performance from the disk, at least in terms of latency. The bandwidth change occurs because the density is fixed and there are more blocks on the outer rings per track compared to the inner rings so in one revolution you can read more tracks and you don't need to change tracks so often. You parent comment is right though, there are only small changes in bit density on the track in recen…

So we went from 1TB to 8TB disks just by packing 3x as many tracks onto drives? I find that hard to believe, and the benchmarks agree with me.

You don't double the write throughout on a disk by doubling the number of tracks. You need more platters and/or sectors per track to do that.

Re: Backblaze hard drive reliability stats for Q3 2016

#113
post #104

Earlier quoted context omitted.

Short stroking helps get more performance from the disk, at least in terms of latency. The bandwidth change occurs because the density is fixed and there are more blocks on the outer rings per track compared to the inner rings so in one revolution you can read more tracks and you don't need to change tracks so often. You parent comment is right though, there are only small changes in bit density on the track in recen…

So we went from 1TB to 8TB disks just by packing 3x as many tracks onto drives? I find that hard to believe, and the benchmarks agree with me. You don't double the write throughout on a disk by doubling the number of tracks. You need more platters and/or sectors per track to do that.

[deleted]

Re: Backblaze hard drive reliability stats for Q3 2016

#114
post #108
post #65

Earlier quoted context omitted.

That's not entirely true. Higher density means more data per track, not just more tracks per disk. You get an entire track per revolution so a track with more data is more MBps. So linear reads on a higher density drive are faster, and semi-linear accesses (ie, reading two files that are next to each other) do get faster. I remember reading a story about a guy who built a drive array with high capacity 7200 RPM drive…

> Higher density means more data per track, not just more tracks per disk. I literally said that: > Most density increases are achieved by packing more tracks onto the platter, while storing more sectors per track plays a minor role.

You are using a different definition of 'minor'. I don't think something that accounts for a 30-100% improvement is minor.

Re: Backblaze hard drive reliability stats for Q3 2016

#115
post #108

Earlier quoted context omitted.

> Higher density means more data per track, not just more tracks per disk. I literally said that: > Most density increases are achieved by packing more tracks onto the platter, while storing more sectors per track plays a minor role.

You are using a different definition of 'minor'. I don't think something that accounts for a 30-100% improvement is minor.

When capacity increased in the same time frame by 800-2000 % then I kinda call that minor.

Re: Backblaze hard drive reliability stats for Q3 2016

#116
post #3

Backblaze is consistently a great service. Needs a Linux client though.

Just use the backblaze API in a script with a cronjob, that's what I do. It's linux, you're going to end up writing some code to get what you want, heh.

Why do you use Backblaze over, say, CrashPlan, if the latter has a Linux client?
Post reply on HN