4 ms·

Assuming you don’t have an early fail drive, it has one usable stat, “Power On Hours”. When that begins to creep towards 40,000 you will have a failed drive soo

Assuming you don’t have an early fail drive, it has one usable stat, “Power On Hours”. When that begins to creep towards 40,000 you will have a failed drive sooner than later. As for the rest of the counter, raw read error rate, relocated sector count and friends are also good indications that your drive might not be in the best shape. They don’t say anything about when it will fail though. I’ve had a drive rack up 20 relocated sectors in a couple of weeks, only to stay at 20 for 4 years after that. And load cycle count is only good for telling if you’re within manufacturer parameters. I frequently see old drives with Load Cycle Count 10-25 times the rated value, and they work just “fine”.

Uberphallus 6y ago
Yeah, the training data is basically useless: 1. Extreme imbalance and survivorship bias. The dataset is unwieldy because of the imbalance, no matter the algorithm; and too small if you balance it. 2. I would take a daily/weekly/monthly diff between different values and time to failure, and obviously only from drives that ACTUALLY failed. All drives fail, but data from healhty drives is useless as it lacks the target value. In practice you want to predict how close they are to failing and act preemptively, tagging them as OK and KO completely misses the target (hehe) IMO. 3. Drive maker and model should be vectorized and fed into the model. Mandatory. Different manufacturers and models show different SMART behaviors, and while some stats are red flags in certain drives, they mean nothing in others. 4. This is more of a personal preference, but I like random trees to test whether the dataset is useful. They're not perfect but they give reasonably good results for most tasks, and tend not to overfit, so you can use it as overfitting benchmark vs other algorithms. If they don't either the dataset is shit or it needs some transformation, or the model needs to be more complex (but that's easy to see). Obviously this applies to classifiers and regressions, and not to many other ML tasks.

Uberphallus 6y ago

Yeah, the training data is basically useless: 1. Extreme imbalance and survivorship bias. The dataset is unwieldy because of the imbalance, no matter the algorithm; and too small if you balance it. 2. I would take a daily/weekly/monthly diff between different values and time to failure, and obviously only from drives that ACTUALLY failed. All drives fail, but data from healhty drives is useless as it lacks the target value. In practice you want to predict how close they are to failing and act preemptively, tagging them as OK and KO completely misses the target (hehe) IMO. 3. Drive maker and model should be vectorized and fed into the model. Mandatory. Different manufacturers and models show different SMART behaviors, and while some stats are red flags in certain drives, they mean nothing in others. 4. This is more of a personal preference, but I like random trees to test whether the dataset is useful. They're not perfect but they give reasonably good results for most tasks, and tend not to overfit, so you can use it as overfitting benchmark vs other algorithms. If they don't either the dataset is shit or it needs some transformation, or the model needs to be more complex (but that's easy to see). Obviously this applies to classifiers and regressions, and not to many other ML tasks.