For those seeking of the code comment. Here it is: <from slashdot.org>
/* EVERY ZNODE'S STORY 1. His infancy. Once upon a time, the znode was born deep inside of zget() by call to zalloc(). At the return from zget() znode had: . reference counter (x_count) of 1 . assigned block number, marked as used in bitmap . pointer to parent znode. Root znode parent pointer points to its father: "fake" znode. This, in turn, has NULL parent pointer. . hash table linkage . no data loaded from disk . no node plugin . no sibling linkage 2. His childhood Each node is either brought into memory as a result of tree traversal, or created afresh, creation of the root being a special case of the latter. In either case it's inserted into sibling list. This will typically require some ancillary tree traversing, but ultimately both sibling pointers will exist and JNODE_LEFT_CONNECTED and JNODE_RIGHT_CONNECTED will be true in zjnode.state. 3. His youth. If znode is bound to already existing node in a tree, its content is read from the disk by call to zload(). At that moment, JNODE_LOADED bit is set in zjnode.state and zdata() function starts to return non null for this znode. zload() further calls zparse() that determines which node layout this node is rendered in, and sets ->nplug on success. If znode is for new node just created, memory for it is allocated and zinit_new() function is called to initialise data, according to selected node layout. 4. His maturity. After this point, znode lingers in memory for some time. Threads can acquire references to znode either by blocknr through call to zget(), or by following a pointer to unallocated znode from internal item. Each time reference to znode is obtained, x_count is increased. Thread can read/write lock znode. Znode data can be loaded through calls to zload(), d_count will be increased appropriately. If all references to znode are released (x_count drops to 0), znode is not recycled immediately. Rather, it is still cached in the hash table in the hope that it will be accessed shortly. There are two ways in which znode existence can be terminated: . sudden death: node bound to this znode is removed from the tree . overpopulation: znode is purged out of memory due to memory pressure 5. His death. Death is complex process. When we irrevocably commit ourselves to decision to remove node from the tree, JNODE_HEARD_BANSHEE bit is set in zjnode.state of corresponding znode. This is done either in ->kill_hook() of internal item or in kill_root() function when tree root is removed. At this moment znode still has: . locks held on it, necessary write ones . references to it . disk block assigned to it . data loaded from the disk . pending requests for lock But once JNODE_HEARD_BANSHEE bit set, last call to unlock_znode() does node deletion. Node deletion includes two phases. First all ways to get references to that znode (sibling and parent links and hash lookup using block number stored in parent node) should be deleted -- it is done through sibling_list_remove(), also we assume that nobody uses down link from parent node due to its nonexistence or proper parent node locking and nobody uses parent pointers from children due to absence of them. Second we invalidate all pending lock requests which still are on znode's lock request queue, this is done by invalidate_lock(). Another JNODE_IS_DYING znode status bit is used to invalidate pending lock requests. Once it set all requesters are forced to return -EINVAL from longterm_lock_znode().*/ On 6/28/07, Alvin Delagon <[EMAIL PROTECTED]> wrote:
A very good read. Took my 2 hours off my office hours! ^_^ "So I take the hint, and that night, in my office, I start scouring the 80,496 lines of the Reiser4 source code. Eventually I stumble across a passage that starts at line 78,077. It's not part of the program itself — it's an annotation, a piece of non-executable text in plain English. It's there for the benefit of someone who has chosen to read this far into the code. The passage explains how memory structures are born, grow, and eventually die. It concludes: 'Death is a complex process.'" That was some hell of a code comment! On 6/28/07, Orlando Andico <[EMAIL PROTECTED]> wrote: > > He sure sounds like a crazy murderer to me! > > > http://www.wired.com/techbiz/people/magazine/15-07/ff_hansreiser?currentPage=1 > _________________________________________________ > Philippine Linux Users' Group (PLUG) Mailing List > [email protected] (#PLUG @ irc.free.net.ph) > Read the Guidelines: http://linux.org.ph/lists > Searchable Archives: http://archives.free.net.ph >
_________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List [email protected] (#PLUG @ irc.free.net.ph) Read the Guidelines: http://linux.org.ph/lists Searchable Archives: http://archives.free.net.ph
