From: Edward Shishkin <edward.shishkin@gmail.com>
To: Ivan Shapovalov <intelfx100@gmail.com>
Cc: reiserfs-devel@vger.kernel.org
Subject: Re: reiser4: FITRIM ioctl -- how to grab the space?
Date: Sun, 10 Aug 2014 21:48:05 +0200 [thread overview]
Message-ID: <53E7CC75.2010500@gmail.com> (raw)
In-Reply-To: <1526377.TUs3NQt8ap@intelfx-laptop>
On 08/10/2014 08:52 PM, Ivan Shapovalov wrote:
> On Friday 01 August 2014 at 01:19:05, Edward Shishkin wrote:
>> On 08/01/2014 12:16 AM, Ivan Shapovalov wrote:
>>> [...]
>>> OK. But it still needs to allocate space (even if just to deallocate it
>>> shortly), which means that someone could get ENOSPC while the discard is in
>>> progress, and this ENOSPC will come from the allocator itself.
>>
>> Ah, yes of course, we'll illegally occupy someone's reservation with
>> the following oops...
>>
>>
>>> Do you have any ideas on how to do it gracefully?
>>
>> 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.
next prev parent reply other threads:[~2014-08-10 19:48 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-31 20:47 reiser4: FITRIM ioctl -- how to grab the space? Ivan Shapovalov
2014-07-31 22:03 ` Edward Shishkin
2014-07-31 22:16 ` Ivan Shapovalov
[not found] ` <53DACEE9.8000802@gmail.com>
2014-08-10 18:52 ` Ivan Shapovalov
2014-08-10 19:48 ` Edward Shishkin [this message]
2014-08-10 20:37 ` Ivan Shapovalov
2014-08-10 23:29 ` Edward Shishkin
2014-08-11 9:39 ` Ivan Shapovalov
2014-08-16 0:44 ` Ivan Shapovalov
2014-08-16 8:09 ` Edward Shishkin
2014-08-16 8:23 ` Edward Shishkin
2014-08-16 11:27 ` Ivan Shapovalov
2014-08-16 13:35 ` Edward Shishkin
2014-08-16 17:05 ` Ivan Shapovalov
2014-08-16 20:13 ` Edward Shishkin
2014-08-16 11:17 ` Ivan Shapovalov
2014-08-16 12:15 ` Edward Shishkin
2014-08-16 17:02 ` Ivan Shapovalov
2014-08-16 19:54 ` Edward Shishkin
2014-08-02 16:40 ` Edward Shishkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53E7CC75.2010500@gmail.com \
--to=edward.shishkin@gmail.com \
--cc=intelfx100@gmail.com \
--cc=reiserfs-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).