[Ocfs2-tools-devel] fsck, lost+found, libocfs2 allocating

[Mark Fasheh]

On Mon, Nov 22, 2004 at 12:30:16PM -0800, Zach Brown wrote:
> I started teaching fsck to really create lost+found and populate it and
> quickly ran into the parts of libocfs2 that need to be fleshed out to
> enable this.  I was testing by trying to force creation of lost+found on
> a freshly made file system and mkfs leaves each node's inode allocator
> chains empty -- including node 0.  It seems reasonable to me that the
> library should try to allocate from all the nodes, expanding them if
> needed, but maybe I've missed out on some conclusive discussion.
Just to make sure I completely understand, the end result wrt lost+found
creation will be that mkfs puts it on a newly created file system? I guess
fsck should be able to create it too if it doesn't exist...
 
> So, barring objections, I think we should:
> 
> - teach ocfs2_new_inode() to try allocating bits from each node.  I
> don't have strong preferences about trying to keep them balanced, or
> anything, I would just walk them in order looking for a free bit.
Normally I'd say don't even bother walking them (just pick a node's
allocator and grow it if necessary, dealing with -ENOSPC by failing the
call). Walking them and figuring out bit usage (by looking at the i_used /
i_total values on dinode) is so easy however, that I won't complain if you
feel inclined to and besides, in the worst situation it's prolly better to
exhaust all suballocators first before growing any.
	--Mark

> - add some input to the chain allocator so that ocfs2_new_inode() can
> ask to have a group created once it has discovered that all the node's
> allocators don't have groups with free bits.
> ocfs2_chain_alloc_expand()?  Whatever.
> 
> - implement ocfs2_chain_alloc_range() as the comments describe to
> allocate the group.  This certainly wants a bitmap _alloc_range() helper
> which will have explicit knowledge of the bitmap regions -- callers just
> using test/set to find the range have to worry about unallocated regions
> and that's no good.
> 
> I'm also holding off on these changes until I hear from Joel that he
> hasn't already implemented them while on a plane :)
> 
> - z
> _______________________________________________
> Ocfs2-tools-devel mailing list
> Ocfs2-tools-devel at oss.oracle.com
> http://oss.oracle.com/mailman/listinfo/ocfs2-tools-devel
--
Mark Fasheh
Software Developer, Oracle Corp
mark.fasheh at oracle.com