summaryrefslogtreecommitdiff
path: root/net/x25
diff options
context:
space:
mode:
authorTao Ma <tao.ma@oracle.com>2008-08-18 17:38:48 +0800
committerMark Fasheh <mfasheh@suse.com>2008-10-13 16:57:01 -0700
commitf56654c435c06f2b2bd5751889b1a08a3add7d6c (patch)
treeb186d68aedc5dda7afe435f5a68c03937ae382ff /net/x25
parentac11c827192272eabb68b8f4cf844066461d9690 (diff)
ocfs2: Add extent tree operation for xattr value btrees
Add some thin wrappers around ocfs2_insert_extent() for each of the 3 different btree types, ocfs2_inode_insert_extent(), ocfs2_xattr_value_insert_extent() and ocfs2_xattr_tree_insert_extent(). The last is for the xattr index btree, which will be used in a followup patch. All the old callers in file.c etc will call ocfs2_dinode_insert_extent(), while the other two handle the xattr issue. And the init of extent tree are handled by these functions. When storing xattr value which is too large, we will allocate some clusters for it and here ocfs2_extent_list and ocfs2_extent_rec will also be used. In order to re-use the b-tree operation code, a new parameter named "private" is added into ocfs2_extent_tree and it is used to indicate the root of ocfs2_exent_list. The reason is that we can't deduce the root from the buffer_head now. It may be in an inode, an ocfs2_xattr_block or even worse, in any place in an ocfs2_xattr_bucket. Signed-off-by: Tao Ma <tao.ma@oracle.com> Signed-off-by: Mark Fasheh <mfasheh@suse.com>
Diffstat (limited to 'net/x25')
0 files changed, 0 insertions, 0 deletions