Pavel Machek wrote:I think that you have to keep in mind the way disk (and other media) fail. You can get media failures after a successful write or errors that pop up as the media ages. Not to mention the way most people run with write cache enabled and no write barriers enabled - a sure recipe for corruption. Of course, there are always software errors to introduce corruption even when we get everything else right ;-) From what I see, media errors are the number one cause of corruption in file systems. It is critical that fsck (and any other tools) continue after an IO error since they are fairly common (just assume that sector is lost and do your best as you continue on). ric --
| david | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Andrew Morton | -mm merge plans for 2.6.23 |
| Greg Kroah-Hartman | [PATCH 025/196] paride: Convert from class_device to device for block/paride |
| Henrique de Moraes Holschuh | [RFC] rfkill class rework |
git: | |
| Gerrit Renker | [PATCH 05/37] dccp: Cleanup routines for feature negotiation |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Johann Baudy | Packet mmap: TX RING and zero copy |
| David Miller | [GIT]: Networking |
