34.4% of RASR failures are not the SSD: 20.5% human mistakes, 13.9% cables, 31.2% labeled Failed Device

The 34.4% figure is two inferred causes added together, not a count of drives that tested healthy. The introduction says that correlating the RASR failures with the repair logs shows a significant number (34.4%) are not caused by the SSD device, and that plugging SSDs into the wrong drive slots, a human mistake, accounts for 20.1%. Section 6 then names the two main non-SSD causes: human mistakes contribute 20.5%, Slot Check plus Mount Options Check, and faulty interconnections fixed by replacing the cable account for 13.9%. Slot Check 20.1 plus Mount Options Check 0.4 equals the printed 20.5, and 20.5 plus 13.9 equals the printed 34.4. The paper does not print those additions. The other Table 11 rows sit outside that 34.4: Rebooting 11.9 (Transient), FSCK 16.5 and Data Check 6.0 (Undetermined; 16.5 + 6.0 = 22.5, not printed), and Replacing SSD 31.2 (Failed Device). Together those are 65.6%. The paper does not print 65.6 and does not call it a device-failure rate. Replacing SSD is the largest single fix, and section 6 still calls it the last resort.

The faults inside the 34.4% are a wrong slot and a bad cable, and the daemon tags both as the SSD. Section 2.2 tags the ticket SSD-related when an SSD appears to be missing. The signal that catches the wrong-slot fault is Slot Check in the repair log. Section 6.2 says plugging the device into the wrong slot, fixed by Slot Check, accounts for 20.1% of RASR failures. That signal misses Mount Options Check, the 0.4% configuration mistakes, and every failure the slot check does not clear. The signal that catches the faulty cable, before the procedure spends its first two attempts, is the Ultra-DMA CRC count. Section 6.1 compares five device errors — UCRC, raw bit error rate, uncorrectable errors, program errors, and end-to-end errors — and says only UCRC has a strong correlation with faulty interconnection. The coefficient is not printed. Seventeen or more UCRC errors, the top 20% of drives, is the Heavy group. On Drive Unfound only, Table 12 shows 70.6% of that Heavy group fixed by replacing the cable, and 12.0% fixed by rebooting or a slot check. The same signal misses a UCRC count from a transient such as a voltage spike, the Light group (cable replacement succeeds for 24.2%), RASR symptoms other than those Drive Unfound rows, and the sensitivity of the threshold, which the paper leaves as future work.

A failure ticket can prove a timestamp, the hardware component the daemon recorded, and a log snippet. It cannot prove the root cause. If the logs name no clear component, the tag is Unknown: 23.7% of all hardware tickets in Table 4, beside CPU 0.7%, memory 8.5%, network 34.0%, motherboard 5.4%, HDD 22.1%, and SSD 5.6%. Section 3.1 says no failure event is tagged with more than one type. Section 2.4 says the daemons may fail to record an event, for example a network failure during log collection, or mistag one, for example a node crash tagged Unknown because the logs were insufficient. A repair log can prove the symptom, the diagnosis procedure, and which candidate in the sequence worked. Section 6 says it does not explicitly state the root cause. The inference the paper states is narrow: if a failure can only be fixed by replacing the SSD, the root cause is likely a failed SSD. What stayed unknown is the Undetermined pair, 22.5%, and the Transient row, 11.9%, where a reboot cleared the symptom and no component was isolated. Section 3.3 orders the candidates by cost and then by past effectiveness, prefers software fixes over slot check, cable replacement, and SSD replacement, and says every RASR failure is eventually fixed by replacing the SSD if the earlier attempts do not work. An early fix that worked was not followed by the later fixes, so the log does not show that those later fixes would have failed. Replacing the SSD shows that the earlier attempts did not work and that the machine was put back. It does not show a separate test that the drive was the only cause.

These shares are RASR tickets from around 450,000 SATA MLC SSDs in 7 Alibaba Cloud datacenters over three years of deployment. The paper states no calendar start or end. They are not a drive-failure rate for that fleet. They are not the later Alibaba NVMe fail-slow census, 4,584 of 779,978 drives with perf logs from 2020-11-16 to 2021-03-05. They are not the Google SMART counts on ATA disks from December 2005 through August 2006, and not the 101 fail-slow reports behind the 112 root-cause occurrences in Gunawi et al. Section 6.2’s One Interface One Purpose deployment, about 100K SSDs over 6 months, reports 3 wrong-slot RASR failures against an average of 47 on a comparable system that still used one interface for every purpose. That is a later population, not a remeasurement of the 20.1%. The 89 Drive Unfound cases and the 21.1% shorter repair time are engineer feedback on cases the paper says are not in the dataset. The DFS and the service software are not open source.