On Mon, 2003-12-01 at 16:52, Zhihui Zhang wrote: > Hi, > > I have been studying JFS on and off for quite a while. But I can never be > as sure as the experts who really work on JFS on a daily basis. So would > you please clarify the following points for me: > > (1) Dirty metapages are usually marked as nohomeok. But metapages for > bitmap seem to be an exception. Why treat bitmap metapage differently? > My guess is because of the careful write strategy JFS is using. If so, > why working bitmap is updated first during an allocation, while permanent > bitmap is updated first during a free?
The working bitmap needs to be updated first during an allocation to prevent another allocation from using the just-allocated blocks. When freeing, the working map is the last to be modified for the same reason -- to prevent a new allocation from using the just-freed blocks before the transaction is complete. The persistent map must reflect the state of committed changes before the journal entries for those transactions can be forgotten. When the journal is replayed, the persistent map is updated according to the journaled transactions being replayed, and the working map is copied from the persistent map. > I understand some metapages (control nodes in the disk space map) does not > need to be logged because their information can be reconstructued easily. > When are they updated normally? When the file system is unmounted. Otherwise they are rebuilt by fsck.jfs. > (2) The directory index table seems to try to bridge the legacy linear > offset and the real cookie in JFS - a leaf node number plus a slot number. > What if an entry's location changes after its index is put into the table > (e.g., a split of leaf node)? Should there be something like > update_index() in addition to add_index() and free_index()? It's called modify_index(), and it gets called when the location of the entry changes. > The size of the directoy is the size of the directory index table. The > index is persistent because it is never reused. The table must grow > forever because freed index is not reused. How is the performance loss > due to maintaing such a large table? Maybe we can simply encode the leaf > node number and the slot number into one 64-bit cookie. That would get rid > of the table. I must miss something? The problem with hashing the leaf node number and slot number is that they change. Early in development, we had a simple hash like this, and rm -rf of a large directory did not remove everything because readdir would not resume at the correct entry. Also, we are unable to use 64 bits for a cookie. If I remember correctly, NFSv2 only uses 31 bits for the cookie, and some user-space applications use only 32 bits. > Thanks for your insights. You are welcome. These are excellent questions, and I'll be happy to answer any more. > > -Zhihui -- David Kleikamp IBM Linux Technology Center _______________________________________________ Jfs-discussion mailing list [EMAIL PROTECTED] http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
