> From: Brandon Allbery [mailto:allber...@gmail.com] > > And it prevents the head scribbling garbage during a power failure how?
I acknowledge that during a power cut, the drive may fail to complete write instructions, resulting in corrupt data in the blocks that the drive had been instructed to overwrite. But it's not going to magically invent new write instructions, jump tracks, or write corrupt data to unexpected blocks. The journal knows which blocks have been signaled for overwrite, so after reboot, the journal knows where the corrupt data may and may not exist. > Think a little, please. It can reduce the need for a fsck. It CANNOT eliminate > it, Some implementations (rotating buffer) may not eliminate the need for fsck. But my recollection from something I read years ago, was that in Ext3, the journal is written on each individual inode, and that all the functions performed by fsck are performed on the fly, upon each inode access. I could be wrong about implementation details, but by even mentioning this possibility, I'm showing that your emphasized "CANNOT" is incorrect. I'm not asserting that journaling DOES eliminate the need for all fsck, I'm only asserting that it CAN, and specifically, it does eliminate the need for fsck after crash. > and you SHOULD periodically do a full check to be certain that other > sources of corruption have not caused problems. Agreed. And if you have end-to-end data integrity, periodic scrub should be performed. But the point of this thread was automatic fsck after system crash. _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
