On 05/07/2014 09:35 AM, Ivan Shapovalov wrote:
On Tuesday 06 May 2014 at 10:58:53, Edward Shishkin wrote:
On 05/03/2014 10:32 PM, Ivan Shapovalov wrote:
On Saturday 03 May 2014 at 22:21:58, Edward Shishkin wrote:
TBH, I have never looked at the deallocation paths in reiser4: everything
worked fine there.. BTW, why not to use atom's delete_set to discard
things? Could you please take a look?
[...]
Blocks used for the journal (wander.c) are deallocated without BA_DEFER
set
and thus they never hit delete_set. However, we want to discard these.
This happens in error paths. Don't be so scrupulous ;)
I don't think so:
- wander.c:485
dealloc_tx_list() <- reiser4_write_logs()
- wander.c:505
dealloc_wmap_actor() <- dealloc_wmap() <- reiser4_write_logs()
Yep, indeed.
I don't completely understand this special case of wandered blocks.
From what I've been able to understand, delete_set is not used there just
because the deallocations are done directly to the bitmaps: we already hold
the tmgr mutex at that time.
Also I don't see where wandered blocks are deallocated after journal
replay (as journal is not needed any more): it can be a possible leak
of disk space after system crashes..
Maybe the bitmap version submitted to disk does not have these blocks
allocated? I don't really understand what's going on wrt. disk write-out, and
I don't even understand the difference between COMMIT BITMAP and WORKING
BITMAP...
I'll try to find the original zam's design document.
It is horribly written and obsolete, but it contains some hints about
who is who..
Once we understand it, I think we'll able to re-use the delete_set for
discard needs.
Edward.
We can get any benefits from re-using delete_set only if we replace it with a
list/rbtree. Current implementation (blocknr_set) seems to be inherently
unordered and can't be trivially modified (extent merge etc), so if we want to
use delete_set as-is, we still need to copy the extents into a better data
structure at commit time.
--
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
