On 08/10/2014 10:37 PM, Ivan Shapovalov wrote:
On Sunday 10 August 2014 at 21:48:05, Edward Shishkin wrote:
On 08/10/2014 08:52 PM, Ivan Shapovalov wrote:
On Friday 01 August 2014 at 01:19:05, Edward Shishkin wrote:
[...]
Define maximal number of allocated blocks in one iteration
and reserve this amount of blocks at the beginning of each
iteration. Once the limit is exhausted, stop the scan and
force to commit the atom.
This sounds pretty hackish... Isn't there a way to grab all possible space
at the same time?
By all possible space I mean (sbinfo->block_count - sbinfo->blocks_used),
so that `fstrim <mountpoint>` will be efficient even if system is under load
and atoms are being created continuously.
I am afraid that other processes will return ENOSPC, whereas there is
a lot of free disk space.
Assume fstrim grabbed all possible space. A process X , who needs to
reserve space invokes txnmgr_force_commit_all(). Everyone waits for
commits completion. After this fstrim grabs all possible space again
(there is no any queue for free space reclaimers). Process X returns
ENOSPC.
Edward.
I've meant "grabbing all space and then allocating all space" -- so there won't
be multiple grabs or multiple atoms.
Then all processes grabbing space with BA_CAN_COMMIT will wait for the discard
atom to commit.
It seems such waiting will screw up the system. No?
(Actually, there is a small race window between grabbing space
and creating an atom...)
Which one?
The only problem is to wait for (sbinfo->block_count == sbinfo->blocks_used +
sbinfo->blocks_free) condition, i. e. until no blocks are reserved in any form,
and then to grab all space atomically wrt. reaching this condition.
Again, if this is not feasible, I'll go with the multiple atoms approach. I
just want to make sure.
--
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
