From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "Richard Weinberger" <richard@nod.at>,
"Artem Bityutskiy" <dedekind1@gmail.com>,
"Adrian Hunter" <adrian.hunter@intel.com>,
linux-mtd@lists.infradead.org, "Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH V2 2/2] ubifs: use dirty_writeback_interval value for wbuf timer
Date: Tue, 20 Sep 2016 10:40:39 +0200 [thread overview]
Message-ID: <20160920104039.1bbe878b@bbrezillon> (raw)
In-Reply-To: <20160920083615.31099-2-zajec5@gmail.com>
On Tue, 20 Sep 2016 10:36:15 +0200
Rafał Miłecki <zajec5@gmail.com> wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Right now wbuf timer has hardcoded timeouts and there is no place for
> manual adjustments. Some projects / cases many need that though. Few
> file systems allow doing that by respecting dirty_writeback_interval
> that can be set using sysctl (dirty_writeback_centisecs).
>
> Lowering dirty_writeback_interval could be some way of dealing with user
> space apps lacking proper fsyncs. This is definitely *not* a perfect
> solution but we don't have ideal (user space) world. There were already
> advanced discussions on this matter, mostly when ext4 was introduced and
> it wasn't behaving as ext3. Anyway, the final decision was to add some
> hacks to the ext4, as trying to fix whole user space or adding new API
> was pointless.
>
> We can't (and shouldn't?) just follow ext4. We can't e.g. sync on close
> as this would cause too many commits and flash wearing. On the other
> hand we still should allow some trade-off between -o sync and default
> wbuf timeout. Respecting dirty_writeback_interval should allow some sane
> cutomizations if used warily.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> V2: Fix delta calculation and make it more clear. Thanks Boris.
> ---
> fs/ubifs/io.c | 8 ++++----
> fs/ubifs/ubifs.h | 4 ----
> 2 files changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/fs/ubifs/io.c b/fs/ubifs/io.c
> index 4d6ce4a..3be2890 100644
> --- a/fs/ubifs/io.c
> +++ b/fs/ubifs/io.c
> @@ -452,11 +452,11 @@ static enum hrtimer_restart wbuf_timer_callback_nolock(struct hrtimer *timer)
> */
> static void new_wbuf_timer_nolock(struct ubifs_wbuf *wbuf)
> {
> - ktime_t softlimit = ktime_set(WBUF_TIMEOUT_SOFTLIMIT, 0);
> - unsigned long long delta;
> + ktime_t softlimit = ms_to_ktime(dirty_writeback_interval * 10);
> + unsigned long long delta = dirty_writeback_interval;
>
> - delta = WBUF_TIMEOUT_HARDLIMIT - WBUF_TIMEOUT_SOFTLIMIT;
> - delta *= 1000000000ULL;
> + /* centi to milli, milli to nano, then 10% */
> + delta *= 10ULL * NSEC_PER_MSEC / 10ULL;
>
> ubifs_assert(!hrtimer_active(&wbuf->timer));
> ubifs_assert(delta <= ULONG_MAX);
> diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
> index 11bc8fa..26e6340 100644
> --- a/fs/ubifs/ubifs.h
> +++ b/fs/ubifs/ubifs.h
> @@ -83,10 +83,6 @@
> */
> #define BGT_NAME_PATTERN "ubifs_bgt%d_%d"
>
> -/* Write-buffer synchronization timeout interval in seconds */
> -#define WBUF_TIMEOUT_SOFTLIMIT 3
> -#define WBUF_TIMEOUT_HARDLIMIT 5
> -
> /* Maximum possible inode number (only 32-bit inodes are supported now) */
> #define MAX_INUM 0xFFFFFFFF
>
next prev parent reply other threads:[~2016-09-20 8:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-14 10:21 [PATCH 0/2] ubifs: respect dirty_writeback_interval Rafał Miłecki
2016-09-16 13:53 ` Richard Weinberger
2016-09-16 14:43 ` Rafał Miłecki
2016-09-20 8:36 ` [PATCH V2 1/2] ubifs: drop softlimit and delta fields from struct ubifs_wbuf Rafał Miłecki
2016-09-20 8:36 ` [PATCH V2 2/2] ubifs: use dirty_writeback_interval value for wbuf timer Rafał Miłecki
2016-09-20 8:40 ` Boris Brezillon [this message]
2016-10-11 21:48 ` [PATCH V2 1/2] ubifs: drop softlimit and delta fields from struct ubifs_wbuf Rafał Miłecki
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=20160920104039.1bbe878b@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=adrian.hunter@intel.com \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=rafal@milecki.pl \
--cc=richard@nod.at \
--cc=zajec5@gmail.com \
/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).