4 ms·

Ok, so everyone has decided that SMR+ZFS is bad. Given that all traditional RAID arrays do online rebuild, what keeps a random application, lets say a database

Ok, so everyone has decided that SMR+ZFS is bad. Given that all traditional RAID arrays do online rebuild, what keeps a random application, lets say a database, from creating a write pattern during the rebuild which forces timeouts? AFAIK, nothing. And logically, it might be possible with just a single drive without the RAID given that WD hasn't published proper command timeout definitions for these drives either. So people are giving them a pass for finally admitting that the drives are SMR. That does nothing if they won't publish topology information, or buffer capacity so that the host can optimize write patterns. So, until the opensource community can adjust the worse case command timeouts, and preferably optimize write patterns based on drive topology, the hardware doesn't appear fit for any purpose.

himinlomax 6y ago
Putting a database on a spinning disk in 2020 is just completely idiotic.
- zepearl 6y ago
  I don't think so - the decision which media to use is linked to a lot of factors (type of database, amount&size of data written/read, type of filesystem, costs, durability, expectations, etc...).
  - himinlomax 6y ago
    You don't think so, I know so. There are a few edge cases where spinning disks could be acceptable, but none where they are superior anymore. Cost? Maybe if you're not billed for electricity. And the cost of hardware is beer money compared to admin/dev/architect time. Durability? Drives of both technology vary in durability based on market class. Enterprise disks are superior to cheap consumer SSDs in that respect, but within the same class SSDs are superior. Type of database? Well if your database is used mostly for sequential reads, in other words when it's for most intents and purposes used like a flat file would be, you're in that edge case. Few individual databases are like that, though admittedly those that are can be very large. Data written/read? Early SSDs were admittedly prone to wearing off with heavy writes. We're long past that, except if you're talking about dodgy SD cards but you're not putting a database on that, are you? Types of filesystems? Just no. Hard drives are cheaper per byte. Significantly cheaper, but not even an order of magnitude cheaper anymore. They use more power, their random access time is orderS of magnitude slower, and their sequential transfer rate is slower. Hell even sequential write is not better any more. But I'll concede this, if you look long and hard enough, I'm sure you can find that one odd case where a database is marginally better served by spinning disks.
    - rasz 6y ago
      >We're long past that its the other way around, we are currently somewhere between 150 and 1000 write cycle endurance and going down with every new node upgrade/cell density bump. https://searchstorage.techtarget.com/definition/write-cycle https://searchstorage.techtarget.com/definition/write-cycle
    - effie 6y ago
      Do you know about OS-level I/O caching/buffering? They make the sequential speed more important. And in case one wants to get faster, there is no need to go all SSD. There is often a lot of data but I/O touches only small part of it, so one can use few fast cache SSDs + many spinning disks in a cluster to achieve good enough performance with better price. There you go, spinning drives still make a lot of sense.
    - zepearl 6y ago
      You seem to be 100% sure about what you wrote (no doubts, questions, clarifications, investigations, discussions, etc...) => go ahead, with that kind of knowledge and attitude you'll most probably be successful at anything that you'll do from every point of view.
- deleted 6y ago
  [deleted]
cbsmith 6y ago
SMR+ZFS doesn't have to be bad, but you'd need a host-aware SMR implementation and then you'd need to make a lot of changes to ZFS to make it effective with SMR. In principle though, it seems like ZFS could actually make great file system to work with SMR drives. I think the complaint is they rolled these out with the SMR effectively hidden by the drive firmware, so a) huge performance impact in cases where caching couldn't save you , b) no easy way for the software guys to address the problem, and c) no way for the customer to know any of this.
- StillBored 6y ago
  "b) no easy way for the software guys to address the problem" Right, from a techical perspective, that is the problem. If WD was transparent about the SMR regions, cache size/full capacity, and read/write timeouts then the drives could be made provably useful (if potentially slow). But they aren't providing that, which is problem 1, your "c" is of course a large part of that problem (lack of transparency). At least intel when they product segment, they tell you what is visibly diffrent between the products (ECC, AVX-512, number of UPI lanes, etc). WD and the drive industry has been trying to hide this information for decades, for a while it was the sonic interference functionality, then it was TLER controls, then the IDLE3 controls. And recently its hard to get a straight answer about things which can be detected from profiling tools (SMR, Rotational speed, number of platters, track to track seek, etc). And for what? The only people being hurt by this are the consumers, which don't know if they should buy a WD purple or a WD red for their video server because no one but their actual competitors spends the time/effort to take the drives apart and profile them to detect what is actually different in the artificial product segments.

himinlomax 6y ago

Putting a database on a spinning disk in 2020 is just completely idiotic.

zepearl 6y ago
I don't think so - the decision which media to use is linked to a lot of factors (type of database, amount&size of data written/read, type of filesystem, costs, durability, expectations, etc...).
- himinlomax 6y ago
  You don't think so, I know so. There are a few edge cases where spinning disks could be acceptable, but none where they are superior anymore. Cost? Maybe if you're not billed for electricity. And the cost of hardware is beer money compared to admin/dev/architect time. Durability? Drives of both technology vary in durability based on market class. Enterprise disks are superior to cheap consumer SSDs in that respect, but within the same class SSDs are superior. Type of database? Well if your database is used mostly for sequential reads, in other words when it's for most intents and purposes used like a flat file would be, you're in that edge case. Few individual databases are like that, though admittedly those that are can be very large. Data written/read? Early SSDs were admittedly prone to wearing off with heavy writes. We're long past that, except if you're talking about dodgy SD cards but you're not putting a database on that, are you? Types of filesystems? Just no. Hard drives are cheaper per byte. Significantly cheaper, but not even an order of magnitude cheaper anymore. They use more power, their random access time is orderS of magnitude slower, and their sequential transfer rate is slower. Hell even sequential write is not better any more. But I'll concede this, if you look long and hard enough, I'm sure you can find that one odd case where a database is marginally better served by spinning disks.
  - rasz 6y ago
    >We're long past that its the other way around, we are currently somewhere between 150 and 1000 write cycle endurance and going down with every new node upgrade/cell density bump. https://searchstorage.techtarget.com/definition/write-cycle https://searchstorage.techtarget.com/definition/write-cycle
  - effie 6y ago
    Do you know about OS-level I/O caching/buffering? They make the sequential speed more important. And in case one wants to get faster, there is no need to go all SSD. There is often a lot of data but I/O touches only small part of it, so one can use few fast cache SSDs + many spinning disks in a cluster to achieve good enough performance with better price. There you go, spinning drives still make a lot of sense.
  - zepearl 6y ago
    You seem to be 100% sure about what you wrote (no doubts, questions, clarifications, investigations, discussions, etc...) => go ahead, with that kind of knowledge and attitude you'll most probably be successful at anything that you'll do from every point of view.
deleted 6y ago
[deleted]

cbsmith 6y ago

SMR+ZFS doesn't have to be bad, but you'd need a host-aware SMR implementation and then you'd need to make a lot of changes to ZFS to make it effective with SMR. In principle though, it seems like ZFS could actually make great file system to work with SMR drives. I think the complaint is they rolled these out with the SMR effectively hidden by the drive firmware, so a) huge performance impact in cases where caching couldn't save you , b) no easy way for the software guys to address the problem, and c) no way for the customer to know any of this.

StillBored 6y ago
"b) no easy way for the software guys to address the problem" Right, from a techical perspective, that is the problem. If WD was transparent about the SMR regions, cache size/full capacity, and read/write timeouts then the drives could be made provably useful (if potentially slow). But they aren't providing that, which is problem 1, your "c" is of course a large part of that problem (lack of transparency). At least intel when they product segment, they tell you what is visibly diffrent between the products (ECC, AVX-512, number of UPI lanes, etc). WD and the drive industry has been trying to hide this information for decades, for a while it was the sonic interference functionality, then it was TLER controls, then the IDLE3 controls. And recently its hard to get a straight answer about things which can be detected from profiling tools (SMR, Rotational speed, number of platters, track to track seek, etc). And for what? The only people being hurt by this are the consumers, which don't know if they should buy a WD purple or a WD red for their video server because no one but their actual competitors spends the time/effort to take the drives apart and profile them to detect what is actually different in the artificial product segments.