Messages in this thread |  | | | Date | Wed, 24 Dec 2003 19:07:39 -0700 | | From | "Eric D. Mudama" <> | | Subject | Re: 2.6.0-test11 data loss |
| |
On Thu, Dec 25 at 9:34, Con Kolivas wrote: >On Thu, 25 Dec 2003 09:22, Gergely Tamas wrote: >> I don't think this is a reiserfs bug. This was my first thought and >> after first hitting this bug, I've moved all my partitions from reiserfs >> to jfs. But I've also had this problem with it... Now I'm back to >> 2.4.23, and everything works fine. > >Because of the numerous reboots and hangs I've seen with experimental patches >I've also seen this, but it's not reiserFS fault. The problem is that most >drives have write caching enabled and not all of them are safe with this. If >you disable it with hdparm (hdparm -W 0 /dev/hd*) you'll find that open files >during a hard reset or power outage will prevent those open files from being >corrupted.
Write cache off will not prevent a file from being corrupted, however, it should limit the corruption to a single disk operation.
I don't see how the behavior you describe could be the drive's fault...
The user stated that their system hard locked, then they went and rebooted it, and following the reboot they had corruption... From this, there are a few possibilities:
1. The drive had been given the commands to write the data prior to the hang.
If this was the case, the drive would happilly keep writing the data it had been given and was caching in the background, even while you continued to send (or stopped sending) data for a new command over the interface. An IDE interface lockup or system lockup will not prevent the drive from flushing the remainder of its write cache. (Only possible exception might be faulty handling of a hard reset, but all drives today will flush their cache when they see the reset, prior to processing it.) Unless the user yanked power within a few hundred milliseconds of the write command, I think it is unlikely that cached data already in the drive wasn't flushed properly.
2. The drive was in the middle of a command writing important data during the hang.
In this case, yes, your file you were writing would probably be corrupt on the media, but nothing more. Drives detect power loss, and immediately disable write-gate and park the actuator. If they don't get the actuator parked before they run out of back-EMF from the momentum of the platter(s), the head will stick to the media and you'll probably need a chisel to get that drive to spin again.
3. The drive hadn't yet been issued the commands for the data that was eventually corrupted.
I find this to be the most likely case, and is a situation where the filesystem thinks objects were moved but those updates were not correctly sent to the disk (due to the hang?), so it might think they're in the old location or something. (I'm not a filesystem wizard so if I'm way off-base, my apologies)
It seems to me that the problem occurred at a higher system level than the disk, and disabling the write cache on the drive (besides being a *HUGE* performance loser) will only make the window for failure smaller, not eliminate it entirely.
Unless you are using *really* old hard drives, the write caching in today's drives is really quite good and definitely should be usable. Sure, it makes things less safe in power events, but system lockups shouldn't affect the drive's ability to flush its cache. Note too that Gergely reported that the problem went away on his 2.4.23 system. I don't believe that to be a small data point.
--eric, posting from home
-- Eric D. Mudama edmudama@mail.bounceswoosh.org
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |