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... > 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. -- Ivan Shapovalov / intelfx / > > >> Also users will use copy-on-write transaction model for their SSDs(*), > >> and in this mode journals are tiny: they contain only system blocks. > >> In short, there is nothing to discard.. > >> > >> (*) http://marc.info/?l=reiserfs-devel&m=139449965000686&w=2
Attachment:
signature.asc
Description: This is a digitally signed message part.
