On 06/17/2014 10:47 PM, Ivan Shapovalov wrote:
On Tuesday 17 June 2014 at 22:31:36, Ivan Shapovalov wrote:
On Tuesday 17 June 2014 at 12:29:53, Edward Shishkin wrote:
[...]
Yup.
So, if discard is on, we work with 2 lists (delete_set,
delete_set_for_wander).
If discard is off, we work with one blocknr set..
Good. So I'll do roughly following for v5:
- rename discard_set_* to block_list_* and split off these definitions
- write a family of reiser4_atom_dset_*() (log_deferred, log_immediate,
apply_deferred, merge, init, destroy) which will encapsulate discard/nodiscard
check and operate on correct lists (blocknr_set vs block_list)
- call reiser4_atom_dset_{init,destroy,merge}() from respective functions
- call reiser4_atom_dset_log_{deferred,immediate}() from reiser4_dealloc_blocks()
- call reiser4_atom_dset_apply_deferred() from reiser4_post_commit_hook()
- directly manipulate the block lists from discard_atom(), checking that we
indeed have discard enabled
Is this OK?
BTW, with txn_atoms there is a locking idiom involving E_REPEAT loops.
Is it fine to implement a
current_atom_dset_log_...(...) // E_REPEAT loop inside
instead of
atom_dset_log_...(txn_atom* atom, ...)
IMHO it is not needed.
atom = get_current_atom_locked();
atom_dset_{defer, immed}_add_extent(atom, ...); // <-- the loop is here
spin_unlock_atom(atom);
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
