We can't dereference "bg" before it has been assigned.  GCC should have
warned about this but "bg" was initialized to NULL.  I've fixed that as
well.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJie Liu <jeff.liu@oracle.com>
Reviewed-by: NJie Liu <jeff.liu@oracle.com>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Joel Becker <jlbec@evilplan.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Smatch complains that if we hit an error (for example if the file is
immutable) then "range" has uninitialized stack data and we copy it to
the user.

I've re-written the error handling to avoid this problem and make it a
little cleaner as well.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJie Liu <jeff.liu@oracle.com>
Reviewed-by: NJie Liu <jeff.liu@oracle.com>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Joel Becker <jlbec@evilplan.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

new helper (wrapper around mnt_drop_write()) to be used in pair with
mnt_want_write_file().
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

it's both faster (in case when file has been opened for write) and cleaner.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Many stupid corrections of duplicated includes based on the output of
scripts/checkincludes.pl.
Signed-off-by: NVitaliy Ivanov <vitalivanov@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

"new_phys_cpos" is always a valid pointer here.
ocfs2_probe_alloc_group() allocates "*new_phys_cpos".
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NJoel Becker <jlbec@evilplan.org>

though the goal_to_be_moved will be validated again in following moving, it's
still a good idea to validate it after adjustment at the very beginning, instead
of validating it before adjustment.
Signed-off-by: NTristan Ye <tristan.ye@oracle.com>

It's not wise enough to do a 64bits division anywhere in kernside, replace it
with a decent helper or proper shifts.
Signed-off-by: NTristan Ye <tristan.ye@oracle.com>

The threshold should be greater than clustersize and less than i_size.
Signed-off-by: NTristan Ye <tristan.ye@oracle.com>

We're going to support partial extent moving, which may split entire extent
movement into pieces to compromise the insuffice allocations, it eases the
'ENSPC' pain and makes the whole moving much less likely to fail, the downside
is it may make the fs even more fragmented before moving, just let the userspace
make a trade-off here.
Signed-off-by: NTristan Ye <tristan.ye@oracle.com>

the basic logic of moving extents for a file is pretty like punching-hole
sequence, walk the extents within the range as user specified, calculating
an appropriate len to defrag/move, then let ocfs2_defrag/move_extent() to
do the actual moving.

This func ends up setting 'OCFS2_MOVE_EXT_FL_COMPLETE' to userpace if operation
gets done successfully.
Signed-off-by: NTristan Ye <tristan.ye@oracle.com>

The helper is to calculate the defrag length in one run according to a threshold,
it will proceed doing defragmentation until the threshold was meet, and skip a
LARGE extent if any.
Signed-off-by: NTristan Ye <tristan.ye@oracle.com>

ocfs2_move_extent() logic will validate the goal_offset_in_block,
where extents to be moved, what's more, it also compromises a bit
to probe the appropriate region around given goal_offset when the
original goal is not able to fit the movement.
Signed-off-by: NTristan Ye <tristan.ye@oracle.com>

These helpers were actually borrowed from alloc.c, which may be publicized
later.
Signed-off-by: NTristan Ye <tristan.ye@oracle.com>

Before doing the movement of extents, we'd better probe the alloc group from
'goal_blk' for searching a contiguous region to fit the wanted movement, we
even will have a best-effort try by compromising to a threshold around the
given goal.
Signed-off-by: NTristan Ye <tristan.ye@oracle.com>

First best-effort attempt to validate and adjust the goal (physical address in
block), while it can't guarantee later operation can succeed all the time since
global_bitmap may change a bit over time.
Signed-off-by: NTristan Ye <tristan.ye@oracle.com>

This function tries locate the right alloc group, where a given physical block
resides, it returns the caller a buffer_head of victim group descriptor, and also
the offset of block in this group, by passing the block number.
Signed-off-by: NTristan Ye <tristan.ye@oracle.com>

It's a relatively complete function to accomplish defragmentation for entire
or partial extent, one journal handle was kept during the operation, it was
logically doing one more thing than ocfs2_move_extent() acutally, yes, it's
claiming the new clusters itself;-)
Signed-off-by: NTristan Ye <tristan.ye@oracle.com>

The moving range of __ocfs2_move_extent() was within one extent always, it
consists following parts:

1. Duplicates the clusters in pages to new_blkoffset, where extent to be moved.

2. Split the original extent with new extent, coalecse the nearby extents if possible.

3. Append old clusters to truncate log, or decrease_refcount if the extent was refcounted.
Signed-off-by: NTristan Ye <tristan.ye@oracle.com>

Ocfs2/move_extents: lock allocators and reserve metadata blocks and data clusters for extents moving.

ocfs2_lock_allocators_move_extents() was like the common ocfs2_lock_allocators(),
to lock metadata and data alloctors during extents moving, reserve appropriate
metadata blocks and data clusters, also performa a best- effort to calculate the
credits for journal transaction in one run of movement.
Signed-off-by: NTristan Ye <tristan.ye@oracle.com>

Adding new files move_extents.[c|h] and fill it with nothing but
only a context structure.
Signed-off-by: NTristan Ye <tristan.ye@oracle.com>