From: Edward Shishkin <edward.shishkin@gmail.com>
To: Ivan Shapovalov <intelfx100@gmail.com>, reiserfs-devel@vger.kernel.org
Subject: Re: reiser4: FITRIM ioctl -- how to grab the space?
Date: Fri, 01 Aug 2014 00:03:58 +0200 [thread overview]
Message-ID: <53DABD4E.1000905@gmail.com> (raw)
In-Reply-To: <3405506.BC0S4TX54B@intelfx-laptop>
grab_space() is only for processes which require disk space (including
wandered blocks). For example ->read() modifies a superblock (atime),
which should be written via journal. So ->read() grab 1 block, etc.
As to FITRIM ioctl: I don't think it needs to reserve disk space at all:
it will
issue only discard requests.
Edward.
On 07/31/2014 10:47 PM, Ivan Shapovalov wrote:
> ...and here is volume 2 of my neverending question series :)
>
> A stub ioctl, placed as I described, seems to work and log a warning each time
> I invoke `fstrim` on anything mounted.
>
> Now on to space allocation. This seems pretty easy in the first approximation:
> reiser4_alloc_blocks_bitmap() seems to do what's needed, finding the nearest
> free extent, not the biggest one. So we could just call reiser4_alloc_blocks()
> plus reiser4_dealloc_blocks(BA_DEFER) repeatedly, while allocations succeed.
>
> However, I suppose we need to grab all free space before proceeding. There is
> no primitive for grabbing all free space, so we need to read block counters,
> calculate amount of space to grab and then call reiser4_grab_reserved()
> (as we want to allocate everything, including the reserved space. This creates
> two problems (as I see it):
> - there is a race between reading block counters (under sb spinlock) and
> performing the grab (which takes the spinlock on its own);
> - if anything will try to grab space during discarding, it will get an ENOSPC,
> while it's better to make the process wait until discarding is completed.
>
> I'm not sure whether the last problem really exists (there is BA_CAN_COMMIT,
> but I don't know whether is it used consistently where possible).
>
> Could you explain these things?
>
> Thanks,
next prev parent reply other threads:[~2014-07-31 22:03 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 [this message]
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
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=53DABD4E.1000905@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).