Truncated files after reboot
Mikael Liljeroth <mikael.liljeroth <at> gmail.com>
2012-07-13 14:22:12 GMT
Hi, I have a problem with my JFS partition and I have a couple of questions.
After an unclean unmount and a restart a couple of files have been truncated to size 0.
I am running linux 2.6.23.
I would really appreciate any help I can get, and I apologize for the huge amount of questions :)
What could be the reason for these 0 sized files? Could a logredo be the reason for this or a fsck?
Could jfs_logdump tell me anything interesting and if so what should I be looking for?
From what I understand JFS does not actually write the log to disk when a transaction is committed. Is this right? And if so, where is the log stored until it is written to disk, and does jfs_logdump show me the log on disk or the log currently buffered somewhere?
The word "buffer" is used in a lot of places regarding the jfs log but I have not found any actual definition of where this buffer is located or how big it is or when it is flushed to the disk. One example taken from "JFS Log" paper:
"In txCommit(), the tlck's are processed and log records are written (at least to the buffer). The affected inodes are "written" to the inode extent buffer (they are maintained in separate memory from the extent buffer). Then a commit record is written".
Then it says:
"After the commit record has actually been written (I/O complete), the block map and inode map are updated as needed, and the meta-data pages are marked 'homeok'."
Why is the block and inode maps updated After the commit record is written, isn't that information important to the transaction? And what does meta-data "pages" refer to in this context? Are the log records called pages, and are they located on disk or in memory?
What I don't understand is when and in what order the log records are written to disk. My current theory is that the "buffers" related to the files that become empty never is written to disk and when my system reboots without unmounting the partition properly the meta-data-changes, (related to the size of the file) are lost.
Is there any way of preventing this from happening in the future.
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
Jfs-discussion mailing list
Jfs-discussion <at> lists.sourceforge.net