On Tue, 2004-12-14 at 08:07 -0600, John Goerzen wrote: > Hello, > > I recently had a system crash, and I have experienced some behavior from > JFS on restart that reminds me of why I switched from reiserfs to JFS. > That's not a Good Thing :-) > > 1. Some files contained data that no process could possibly have been > writing to them. It appeared to be blocks of NULLs in some cases. Some > files were .so files, and I lack the expertise to know specifically > which chunks were bad, but I did know that they were corrupt (ldconfig > told me). Some of the files may have contained blocks from other files > also (but I'm not certain of this either).
This can normally happen for files that are created shortly before the crash. Blocks of nulls may be file holes. I don't think .so files are created sequentially, so it may be possible that there are portions of the file that had not yet been committed to disk. It's possible that newly-created files may contain stale data, but I don't think this happens often in practice (but I'm not sure). > 2. Some files were truncated. This is not unexpected in a crash > situation, but there were many more files like this than I would have > expected. This would be normal if the files were newly-created. The transaction that creates the file will be committed to disk earlier than the transaction(s) which extend the file when data is written. > 3. The total number of files touched by #1 and #2 far exceeds the number > of files open for writing at the instant the system went down. Files aren't committed when they are closed. pdflush usually makes sure dirty data is committed to disk within 30 seconds. I believe the typical laptop mode configuration changes the pdflush interval to 10 minutes. > fsck didn't seem to really help. Just to make sure there isn't anything abnormal going on, did fsck run through all of it's phases, or just phase 0? Use the -f or -n flags to force it to check everything. > Is this behavior expected from JFS? Is there anything I can do to help > out next time? As long as the affected files were all created or extended within /proc/sys/vm/dirty_writeback_centisecs, this is expected behavior. > I'm running a stock 2.6.6 kernel on this machine. > > -- John -- David Kleikamp IBM Linux Technology Center _______________________________________________ Jfs-discussion mailing list [EMAIL PROTECTED] http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
