On 07/08/2010 07:14 PM, William A. (Andy) Adamson wrote: > On Thu, Jul 8, 2010 at 6:16 AM, Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: >> On 07/08/2010 01:34 AM, andros@xxxxxxxxxx wrote: >> >> Why don't we allocate this at inode allocation. > > We don't know if we need it at inode allocation. Remember, GFS2 only > uses RO layouts. right! optimize for a specific File System (broken at that). I don't mind if you leave the current code placement and allocate layout_type on first layout-request (first call to _pnfs_update_layout) Then deallocate at inode destruction. The few places that couple the destruction of all layout segments and return them, with the layout_type structure deallocation should just be de-coupled. Don't mix up between the allocation/deallocation of layout_type and destruction of layout-segments. > Plus, the protocol allows a file system to use more > than one layout type and each layout type has a different private > portion of the layout structure. We don't support that, now, for other reasons. Lets not go there. > > > Actually this is not true. pnfs_destroy_layout is not only called a > inode destruction - it is also called in pnfs_reclaim_layout (state > reclaim after reboot) > > In this case, the layout will be destroyed while the inode continues on. > You mean the layout-segments. But the layout_type can stay, why deallocate it? it will be needed again. > The use and implementation of pnfs_reclaim_layout needs a review. > > The question is, when should the nfs_inode->layout be freed when the > inode is not? These are candidates. > - reclaim state after server reboot (current code does this) > - reclaim state after a network partition (current code does this) > - file system migration > - switching to a different file system replica > - CB_LAYOUTRECALL FSID > - CB_LAYOUTRECALL ALL > None of the above. These are all related to on-the-line layouts which are layout-segments in our code. The governing structure is just an inode-thing/per-layout-type. If we follow my simple rules then you see that all these run-away pnfs flags and states that where put back into nfsi can return to ->layout. Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
