On 07/21/2014 01:14 AM, Ivan Shapovalov wrote:
On Monday 21 July 2014 at 00:49:14, Edward Shishkin wrote:
[...]
Actually, this is not so simple. E.g. I got a deadlock..
Another option is to make head/tail paddings dirty with the
following update of the extent of the delete_set.
One more option is to not support such discard params.
Actually what we are trying to implement is "precise discard". This is
rather complicated task. I looked at other file systems: nobody bother
with paddings, just stupidly pass a freed extent to blkdev_issue_discard(),
which cuts the head and the tail. I suggest to do the same. We have done
our best. Someone can not afford even to accumulate the extents.
Edward.
Let's do it ideally, after all, this is reiser4 ;) I also think that we can
just mark paddings as allocated and add them to extent in question (so that
they will be freed by reiser4_post_commit_hook). This looks simple enough.
The block allocator interface, IIRC, allows us to tell it "allocate right here
or return failure".
/* I had no time to look into any code during this weekend. Tomorrow I'll
hopefully repost the discard-before-dealloc patches and look into this.. */
I think we'll also need a "leftward" version of check_blocks() to check
head paddings. The most unpleasant thing is when check fails at the
next bitmap node. It seems that the most reasonable way in this case
would be just to return 0 (dirty) and clear everything when applying
the "updated" delete set.
Edward.
--
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
