All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Richard Weinberger <richard@sigma-star.at>,
	Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: UBIFS orphans and ro-mounts
Date: Wed, 13 Jul 2016 15:48:18 +0300	[thread overview]
Message-ID: <1468414098.18533.34.camel@gmail.com> (raw)
In-Reply-To: <57863442.1000303@sigma-star.at>

On Wed, 2016-07-13 at 14:29 +0200, Richard Weinberger wrote:
> Artem,
> 
> I wonder why UBIFS processes orphan inodes also when mounting read-
> only.

Well, people expect UBIFS to report correct free/used space even if it
is R/O, right? :-)

> Depending on the workload before a power cut this can take a few
> seconds
> and since we mount read-only the updated TNC will not written back to
> flash,
> so upon next mount the time is again wasted.

I see the problem, but I do not agree with word "wasted", because this
is like doing it for nothing, while UBIFS is doing this for a reason.
So I'd rather used word "spent". :-)

> This hurts boot performance a lot on systems where u-boot loads the
> kernel
> from UBIFS.
> u-boot always mounts UBIFS read-only.
> So even when Linux mounts UBIFS rw and a powercut happens orphan
> processing
> will happen twice.

Sure, because in the R/O case the results of that processing cannot be
"saved" on the media, so they have to be repeated.

> I'd suggest calling ubifs_mount_orphans() only when we mount rw or
> remount to
> rw.
> What do you think?

I understand the problem. I do not think this is the right solution
because it'll introduce a regression (incorrect used/free space). But a
special mount option and/or superblock flag may be considered, if this
helps substantially.

  reply	other threads:[~2016-07-13 12:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-13 12:29 UBIFS orphans and ro-mounts Richard Weinberger
2016-07-13 12:48 ` Artem Bityutskiy [this message]
2016-07-13 12:55   ` Richard Weinberger
2016-07-13 16:21     ` Artem Bityutskiy

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=1468414098.18533.34.camel@gmail.com \
    --to=dedekind1@gmail.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@sigma-star.at \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.