Mark Hahn wrote:
[--snip--]
I assume that the disk will indeed do writeback if left idle for a little
while. on machines where this is a real problem, I would start out by
waving relevant chickens like the following to give the best chance of
shutting down cleanly:
sync
blockdev --flushbufs
hdparm -W 0
sleep 2
hdparm -y
sleep 5
halt -hp
rather than _always_ suffering the penalty of disabled write cache,
especially on a single slow laptop drive...
This is slightly OT as this thread is talking about normal power down
but disabling writeback cache has its advantages. When you have power
fluctation (e.g. power source fluctation or new device hot plugged and
crappy PSU can't hold the voltage), the harddisk could briefly power
down while other parts of system keep running. If the disk was under
active FS writes, this ends up in inconsistencies between what the OS
thinks the disk has and the disk actually has.
Unfortunately, this can result in *massive* destruction of the
filesystem. I lost my RAID-1 array earlier this year this way. The FS
code systematically destroyed metadata of the filesystem and, on the
following reboot, fsck did the final blow, I think. I ended up with
100+Gbytes of unorganized data and I had to recover data by grep + bvi.
This is an extreme case but it shows turning off writeback has its
advantages. After the initial stress & panic attack subsided, I tried
to think about how to prevent such catastrophes, but there doesn't seem
to be a good way. There's no way to tell 1. if the harddrive actually
lost the writeback cache content 2. if so, how much it has lost. So,
unless the OS halts the system everytime something seems weird with the
disk, turning off writeback cache seems to be the only solution.
--
tejun
-
: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
