Граф коммитов

6 Коммитов

Автор SHA1 Сообщение Дата
Mark Fasheh 59a5e416d1 ocfs2: plug truncate into cached dealloc routines
Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
2007-07-10 17:31:55 -07:00
Mark Fasheh 2b604351bc ocfs2: simplify deallocation locking
Deallocation of suballocator blocks, most notably extent blocks, might
involve multiple suballocator inodes.

The locking for this can get extremely complicated, especially when the
suballocator inodes to delete from aren't known until deep within an
unrelated codepath.

Implement a simple scheme for recording the blocks to be unlinked so that
the actual deallocation can be done in a context which won't deadlock.

Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
2007-07-10 17:31:54 -07:00
Mark Fasheh 1fabe1481f ocfs2: Remove struct ocfs2_journal_handle in favor of handle_t
This is mostly a search and replace as ocfs2_journal_handle is now no more
than a container for a handle_t pointer.

ocfs2_commit_trans() becomes very straight forward, and we remove some out
of date comments / code.

Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
2006-12-01 18:28:28 -08:00
Mark Fasheh da5cbf2f9d ocfs2: don't use handle for locking in allocation functions
Instead we record our state on the allocation context structure which all
callers already know about and lifetime correctly. This means the
reservation functions don't need a handle passed in any more, and we can
also take it off the alloc context.

Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
2006-12-01 18:27:49 -08:00
Mark Fasheh 883d4cae4a ocfs2: allocation hints
Record the most recently used allocation group on the allocation context, so
that subsequent allocations can attempt to optimize for contiguousness.
Local alloc especially should benefit from this as the current chain search
tends to let it spew across the disk.

Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
2006-08-07 11:07:01 -07:00
Mark Fasheh ccd979bdbc [PATCH] OCFS2: The Second Oracle Cluster Filesystem
The OCFS2 file system module.

Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel@oracle.com>
2006-01-03 11:45:47 -08:00