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. (Actually, there is a small race window between grabbing space and creating an atom...) 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. -- Ivan Shapovalov / intelfx /
Attachment:
signature.asc
Description: This is a digitally signed message part.
