Vladimir Mitiouchev wrote: > Oliver Fromme wrote: > > And if you did, you should newfs(8) the file system when > > you replaced the cables with good ones. > > Q: Why fsck is not enough?
fsck(8) is only able to detect certain (not even all, I believe) inconsistencies in the meta data of a file system. And if you're lucky, it can repair it without losing data. However, fsck can neither detect nor repair any damage in the contents of files. Obviously, the bad IDE cable that you had caused some damage to the meta data of your file systems. It seems like some write accesses succeeded, while others did not, and maybe some write operations even wrote wrong data to the disk. Given the average ratio of meta-data to file-data, chances are that file contents also suffered from the accident. In other words, it is possible that you have garbage in some files, without you knowing. It could be in obvious places, such as kernel sources ... In that case you will get compilation errors next time you try to compile a kernel. Unless, of course, the garbage happens to be valid C code, which is entirely possible, for example if only a few bits toggled in a numeric constant. Then you won't notice, but your new kernel might exhibit subtle misbehaviour, and it'll be _very_ tough to find out what's going on. I suspect that quite a number of FreeBSD PRs are just caused by toggled bits due to bad hardware, wasting significant amounts of developer resources for hunting the "bug". I could go on with many more examples, but you probably got the idea. That's the reason why you should use newfs and restore from backup when an unknown amount of damage happened to a file system due to hardware failure. (I also mentioned that a RAID1 setup could prevent such damage. To detect damage in files, you can also use an intrusion-detection tool like tripwire, mtree or similar.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way.
