Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Samsung ships the world's highest capacity SSD, with 15TB of storage

computerworld.com

Post reply on HN
Print view View original

61–70 of 147 posts

Re: Samsung ships the world's highest capacity SSD, with 15TB of storage

#61

Post by deelowe »

userbinator wrote: post #21

The 15.36TB PM1633a drive supports one full drive write per day, which means 15.36TB of data can be written every day on a single drive without failure over its five-year warranty. In other words, assuming good wear leveling, each bit can only be rewritten ~2K times, which is actually quite low for endurance... the capacity is high and they're using that to hide the fact that it's low, but if this was e.g. SLC flash…

Given how SSDs work, this is actually pretty good reliability. No one is going to be writing the full disk of 15 TB of data every day.

Re: Samsung ships the world's highest capacity SSD, with 15TB of storage

#62

Post by ars »

cookiemonsta wrote: post #36
ars wrote: post #17

Earlier quoted context omitted.

> The first disk died late on Friday. I had two on-hand so I casually replaced it -- and before I got back to my desk another had died. That happens very very very often. It has nothing to do with a bad batch. The second disk actually failed a while ago, but no one noticed because no one read from that part of it. When you did the rebuild you read from the failed area and woke up the failure. When you setup raid you…

Is there a well known tool to check for this?

If you are using software raid on linux then:

1. install mdadm and configure it to run /usr/share/mdadm/checkarray every month. (The default on debian.)

2. have it run as a daemon constantly monitoring for problems. (Also the default on debian.)

3. test that it actually works by setting one of your raid devices faulty and making sure you get an instant email. A tool that detects a problem and can't tell you is quite useless.

4. install smartmontools and configure /etc/smartd.conf to run nightly short self tests, and weekly long self tests. Something like: /dev/sda -a -o on -S on -m email@domain.com -s (S/../.././02|L/../../6/03)

5. do a test of smartmontools by adding -M test to the line above to make sure it is able to contact you

This way you will find out about problems with the disk before they grow large.

There are other settings for smartmontools to monitor all the SMART attributes and you can tell it when to contact you.

6. Extra credit: Install munin or other system graphing tools and graph all the SMART attributes. Check it quarterly and look for anomalies. Everything should be flat except for Power_On_Hours.

Re: Samsung ships the world's highest capacity SSD, with 15TB of storage

#63

Post by uxcn »

Dylan16807 wrote: post #59
uxcn wrote: post #58

Earlier quoted context omitted.

> If you have a single table that's 100GB in size, you can parse through every single row in just under a minute! You're forgetting seek latency. It's orders of magnitude better with SSD, but it's still not necessarily zero. Depending on how the data is laid out and queried you can pay the seek cost per row, which multiplied by the number of rows (100GB+) isn't trivial.

It's a pretty bad database that can't queue up enough reads to keep the drive constantly active during a full-table scan.

It's a throughput problem, not an activity problem. Normally, since the rows are a fixed size the dbms will lay them out sequentially on disk. So, when the database reads from disk unless you read every column in the row, the dbms has to skip over data. This is kind of a high level picture, but hopefully it illustrates the point.

Nearly all of the tick (>4GB/day) databases I've used aren't laid row oriented.

Re: Samsung ships the world's highest capacity SSD, with 15TB of storage

#64

Post by _wmd »

uxcn wrote: post #63
Dylan16807 wrote: post #59

Earlier quoted context omitted.

It's a pretty bad database that can't queue up enough reads to keep the drive constantly active during a full-table scan.

It's a throughput problem, not an activity problem. Normally, since the rows are a fixed size the dbms will lay them out sequentially on disk. So, when the database reads from disk unless you read every column in the row, the dbms has to skip over data. This is kind of a high level picture, but hopefully it illustrates the point. Nearly all of the tick (>4GB/day) databases I've used aren't laid row oriented.

This is so far off the mark..

Even in the absence of variable-width fields, the presence of nullable fields causes the majority of database tables to have variable-width rows. In any case, neither of these are reasons why common databases do or do not lay rows out sequentially on disk (some do, some don't).

Even if the DB server selectively read columns of each row (none of the common open source SQL databases do), they do so via the OS, which works in terms of pages. Reading a single byte of a page will cause a minimum of 4kb of IO to be made to the disk.

Now, unless you're using a DB server that uses O_DIRECT or POSIX_FADV_RANDOM (I just checked and Postgres doesn't), Linux will aggressively readahead at least (it's tunable) 128kb for any random read by default, so even issuing a one byte read to the kernel, device IO will still only occur in a minimum of 128kb chunks, with the remainder living in the page cache until userspace requests it.

Database servers additionally are very likely to have their own larger-than-a-byte-sized buffers in order to avoid system call latency, so the requests they make are never going to be quite so small.

The logic being that in the days of spinning media, evicting 124kb of cold page cache in favour of avoiding a seek a few microseconds later was definitely worth it (a seek being a ~14ms stall on rotating disks)

Re: Samsung ships the world's highest capacity SSD, with 15TB of storage

#65

Post by uxcn »

_wmd wrote: post #64
uxcn wrote: post #63

Earlier quoted context omitted.

It's a throughput problem, not an activity problem. Normally, since the rows are a fixed size the dbms will lay them out sequentially on disk. So, when the database reads from disk unless you read every column in the row, the dbms has to skip over data. This is kind of a high level picture, but hopefully it illustrates the point. Nearly all of the tick (>4GB/day) databases I've used aren't laid row oriented.

This is so far off the mark.. Even in the absence of variable-width fields, the presence of nullable fields causes the majority of database tables to have variable-width rows. In any case, neither of these are reasons why common databases do or do not lay rows out sequentially on disk (some do, some don't). Even if the DB server selectively read columns of each row (none of the common open source SQL databases do), t…

> Even if the DB server selectively read columns of each row (none of the common open source SQL databases do), they do so via the OS, which works in terms of pages. Reading a single byte of a page will cause a minimum of 4kb of IO to be made to the disk.

This is why I said it was high level, but hopefully illustrated the point. In addition to the disk page size, you also have all the various metadata associated with the file(s). So, reading a byte from a page can imply reading even more data than the block size (4KiB current).

> Now, unless you're using a DB server that uses O_DIRECT or POSIX_FADV_RANDOM (I just checked and Postgres doesn't), Linux will aggressively readahead at least (it's tunable) 128kb for any random read by default, so even issuing a one byte read to the kernel, device IO will still only occur in a minimum of 128kb chunks, with the remainder living in the page cache until userspace requests it.

AFAIK, Linux only reads ahead if it detects a sequential pattern, or if you specify POSIX_FADV_SEQUENTIAL (double normal). But, as far as the query is concerned, all of the data read that isn't necessary is effectively subtracted from the overall throughput.

I was trying to illustrate the importance of seek latency (~80us vs. ~9-14ms), but yes there are a myriad of other concerns when you're trying to maximize disk throughput.

Re: Samsung ships the world's highest capacity SSD, with 15TB of storage

#67

Post by ashmud »

sp332 wrote: post #37
bluedino wrote: post #32

Earlier quoted context omitted.

10,000 USD?

I don't see any SAS SSD's going for much less than $1,000/TB. Some of them are twice that! And I'm sure the density will let it command a premium by targeting users who really need more storage in tight spaces. My guess is $50,000.

About 20 years ago, I worked on a project replacing/rewriting servers and their management software for a manufacturer. They had an already aging *nix system (circa 1990). Story went that not long before we came in for the project they had to replace a HDD that was out of production to the tune of about $50k.

Re: Samsung ships the world's highest capacity SSD, with 15TB of storage

#68

Post by dahart »

dorfsmay wrote: post #54
userbinator wrote: post #49

Earlier quoted context omitted.

On the other hand, I still remember when hard drives (the spinning platter ones) reached the $1/GB mark ~10 years ago. Now high-end SSDs are there. A billion bits of storage costing $1 is pretty amazing, I think.

Our brain thinks linear, technology grows exponentially. http://www.kurzweilai.net/the-law-of-accelerating-returns

Kurzweil also claims, as the capstone final paragraph in this piece, that human life expectancy is on an exponential curve, which is false. Not just a little wrong, it's all the way wrong, and intentionally misleading, there's no possible way he doesn't know it's false. It's very easy to check the basic facts: https://en.m.wikipedia.org/wiki/Life_expectancy. Lifespan for people who live past 20 (discounting infant mortality) has been around 70 for at least a thousand years. It's gone up a little in developed countries recently, but he intentionally uses only a small window of time, and includes infant mortality in his stats. If we eliminate all infant mortality, still nobody will live forever, and average lifespan will not be on an exponential curve. This intentionally misleading falsehood alone makes me doubt all the rest of his claims about exponential and double exponential trends. (And I don't doubt Moore, only the additional unsupported implications and loose associations that Kurzweil adds to Moore's law.)

Re: Samsung ships the world's highest capacity SSD, with 15TB of storage

#70

Post by cm2187 »

rsync wrote: post #48
Freaky wrote: post #26

Earlier quoted context omitted.

> As if both drives do exactly the same writes at the same time, chances are they will fail at the same time. You mean due to exhausting their endurance? This is something you monitor, you should have plenty of time to replace the drives before it becomes a concern. For other failures, how's it going to be any different from normal HD's? There's always the risk that having the same models/batches in the same conditio…

"You mean due to exhausting their endurance? This is something you monitor, you should have plenty of time to replace the drives before it becomes a concern. For other failures, how's it going to be any different from normal HD's? There's always the risk that having the same models/batches in the same conditions might lead to a cluster of failures, but RAID's still likely to save you from plenty of other failure mode…

I am actually referring to endurance. Irrespective of the RAID mode, I would expect each drive to be written exactly the same amount of data at the same time. If all models are identical and have been purchased at the same time, one would expect that the same firmware will allocate the same writes to the same cells (in RAID 1 it will be the same data, in RAID 5 the data will be slightly different, but the size will be the same). So in theory the wear should be identical. Obviously this only applies to a RAID mode where you have parity.

But I read that like 3-4y ago. We should have more experience with SSDs in production now so I was wondering if that thinking still applied.

Post reply on HN