[Ocfs2-devel] [PATCH 07/16] Add extent tree operation for xattr value.

[Mark Fasheh]

On Thu, Aug 21, 2008 at 09:35:24AM +0800, Tao Ma wrote:
> Mark Fasheh wrote:
> >[ Joel, good catch ]
> >
> >On Thu, Aug 21, 2008 at 09:03:09AM +0800, Tao Ma wrote:
> >  
> >>>BUG when growing that xattr extent tree?
> >>>	Next, a few lines down:
> >>>
> >>>        mlog_bug_on_msg(!ocfs2_sparse_alloc(osb) &&
> >>>                        (OCFS2_I(inode)->ip_clusters != cpos),
> >>>                        "Device %s, asking for sparse allocation: inode 
> >>>                        %llu, "
> >>>                        "cpos %u, clusters %u\n",
> >>>                        osb->dev_str,
> >>>                        (unsigned long long)OCFS2_I(inode)->ip_blkno, 
> >>>                        cpos,
> >>>                        OCFS2_I(inode)->ip_clusters);
> >>>
> >>>Won't that BUG() when cpos of an xattr extent is not matching the
> >>>ip_clusters of the data?
> >>>  
> >>>      
> >>yeah, you are right, we should move these 2 into 
> >>ocfs2_dinode_insert_extent. thx.
> >>    
> >
> >It might be a good idea for us to run this on a file system without sparse
> >file support to catch any issues that don't show up during review. 
> >Probably,
> >running with / without inline-data helps too. Conceptually though, we 
> >should
> >be safe - anything that supports EA's has all the sparse-file code,
> >regardless of whether we allow the inode data btree to be sparse or not.
> >It's all just a matter of making sure the proper checks are in the right
> >place.
> >  
> Yes, we may need to add some test cases for inline-data volume. As for 
> sparse, currently, in Tiger's mkfs patch, xattr depends on sparse, so it 
> will add sparse automatically, so I am not sure whether we can test 
> xattr without sparse.

It should *not* depend on sparse. I'm pretty sure we discussed this
already...
	--Mark

--
Mark Fasheh