Bug 105281
| Summary: | Write cache gets auto-disabled by the kernel for no obvious reason | ||
|---|---|---|---|
| Product: | IO/Storage | Reporter: | Andreas E (andi3) |
| Component: | Serial ATA | Assignee: | Tejun Heo (tj) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | szg00000, tom.ty89 |
| Priority: | P1 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 4.2.0-10-generic | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
I strongly belive that some, if not all, (S)ATA drives will preserve the settings over a reboot, but not a poweroff. I have two Intel SATA SSDs of different models, one is connected to SATA directly, one is connected to USB through an adapter (which means there's no way for libata to touch it). They both show the same behaviour as I mentioned above. I also have a SanDisk Extreme USB 3.0 which is technically a USB-SATA bridged drive as well. I can set WCE and DRA with hdparm / smartctl successfully and see the value changed with -I / -g all. However, unlike the two Intel SSDs, the settings will not even survive a reboot. So obviously the behaviour is completely hardware-specific. Btw there're some options in hdparm / smartctl which might be relevant to the preservation of settings. For example -k and -K / -S. They do NOT seem to make any changes for me, but you may try if you're interested. P.S. If you still have doubt on libata you may try to test with `hdparm -A0|1 /dev/sdX` or `smartctl --set lookahead,on|off /dev/sdX` to see if the problem shows up for DRA as well, since currently libata has no way to touch it (and I even filed a bug report for that). >I strongly belive that some, if not all, (S)ATA drives will preserve the >settings over a reboot, but not a poweroff. YESSS. That must be it! Meanwhile (remember this bug is almost 2 weeks old now) I did more tests, and yes, settings were mostly (not always, but almost) kept when doing a WARM REBOOT. Once I power-cycled the machine, however, settings were gone. >Btw there're some options in hdparm / smartctl which might be relevant to the >preservation of settings. For example -k and -K / -S. They do NOT seem to make >any changes for me, but you may try if you're interested. Thanks! I will delve myself to that stuff again. And still...I'm not too amused. I mean, is this sensible to always have to manually enable W-C by a rule in, say, /etc/init.d ? Feels like ancient times, somehow. Anyways, thanks for your most useful comment. errata should read "delve through"...whoops >
> And still...I'm not too amused. I mean, is this sensible to always have to
> manually enable W-C by a rule in, say, /etc/init.d ? Feels like ancient
> times, somehow.
>
For that I am not sure about what to tell, since some people might actually prefer that they won't be able to make "permanent" changes to the drives' settings. Also this could be a common practice among hard drive vendors (or even something in the ATA spec?).
If I were having the need to make these changes persistent, I would probably write some systemd service of `smartctl --set` which will be "wanted" after the disks are found AND the system is resumed from sleep. (No idea about how other init work these days, sorry :P)
udisksd is the only so-called "daemon" I've ever know that can be used to set WCE (and APM). However it doesn't seem to do anything after a suspend, which was something that the settings won't survive through as well in my tests.
udisksd...hmmm... Well, perhaps it's even possible to define a udev rule for that task. See, I can even force the letter X for a certain drive called /dev/sdX, so why shouldn't it be possible to enforce the activation of WCE by such rule as well? Sure you can, it just I doubt that you can make udev deal with the reset caused by a suspend/hibernation, though it might be a good supplement to make sure that the settings persist with a "plug cycle". |
I've run into a somewhat enigmatic problem with a drive's write caching. Even though I know how to do that in software (i. e. turn on W-C on each new boot sequence by adding a "rule" in runlevel 5), I want to know WHY this always happens again This drive is a 1 TB Hitachi HITACHI HUA721010KLA330. Both ways work, but never permanently: # hdparm -W1 /dev/sdb # sdparm --set=WCE /dev/sdb The following way (which appears to indicate a permanent setting) does NOT work (as shown): # sdparm --set=WCE --save /dev/sdb /dev/sdb: ATA HITACHI HUA72101 A90A change_mode_page: mode page indicates it is not savable but '--save' option given (try without it) "Not savable", whatever that means. o_O This drive does not allow write cache to be enabled permanently? Gimme a break. I am 99% sure that it's the kernel (libata again??) that auto-disabled W-C. Unfortunately though, there is NOTHING in the dmesg log about why it did that. Oddly enough sometimes it does work, even after a reboot. So perhaps the problem is related to hot-plugging the drive? That is, I detach the SATA data cable, and --plop-- the W-C is disabled again. That might be it, but it's only an assumption.