On Wed, Jun 11, 2008 at 4:26 PM, Yaakov Nemoy <<a href="mailto:loupgaroublond@gmail.com">loupgaroublond@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Journaling won't save you from this problem, necessarily. What you<br>
gain from journaling is when your process aborts half way through<br>
because of any failure at all. The integrity you get is not that<br>
every piece of data is intact and correct, but that no bit is in a<br>
transitory state. This means any transaction, or change of state from<br>
A to B, that affects more than one bit on the hard drive, is a<br>
concrete, isolated and discrete change. This is the only guarantee<br>
you get from a journaled file system.</blockquote><div><br>I again point out this is a file that was written once and never again modified. Nothing should have been writing to it. The metadata got trashed somehow, as I remember it gave some "inode has wrong size" error, I told e2fsck to fix it and the file ended up 0 bytes. I don't see how this could be blamed on anything but the kernel or hardware, and this particular machine is fairly new, with decent quality hardware, so I'm pretty certain the hardware isn't flaky.<br>
<br>Though now that I think of it I've had problems with the r300 drivers locking up the system. Should a hardware lockup cause this kind of problem? If you ask me, no, not to a file that's not even open. Especially as I obsessively type "sync" before doing anything at all risky, but it seems I can't necessarily even trust sync to do its job. Go figure.<br>
</div></div>