On Monday 11 August 2014 at 01:29:59, Edward Shishkin wrote: > > 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? I was afraid of such situations, but how would that happen? The discard atom's commit will always be able to proceed as it doesn't grab space at all. > > (Actually, there is a small race window between grabbing space > > and creating an atom...) > > > Which one? BA_CAN_COMMIT machinery does wait only for atoms, not for contexts. If process X happens to grab space between us grabbing space and creating an atom, it will get -ENOSPC even with BA_CAN_COMMIT. -- Ivan Shapovalov / intelfx / > > 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. > > >
Attachment:
signature.asc
Description: This is a digitally signed message part.
