* UBIFS orphans and ro-mounts @ 2016-07-13 12:29 Richard Weinberger 2016-07-13 12:48 ` Artem Bityutskiy 0 siblings, 1 reply; 4+ messages in thread From: Richard Weinberger @ 2016-07-13 12:29 UTC (permalink / raw) To: Artem Bityutskiy, Boris Brezillon; +Cc: linux-mtd@lists.infradead.org Artem, I wonder why UBIFS processes orphan inodes also when mounting read-only. 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. 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. I'd suggest calling ubifs_mount_orphans() only when we mount rw or remount to rw. What do you think? Thanks, //richard -- sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria ATU66964118 - FN 374287y ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: UBIFS orphans and ro-mounts 2016-07-13 12:29 UBIFS orphans and ro-mounts Richard Weinberger @ 2016-07-13 12:48 ` Artem Bityutskiy 2016-07-13 12:55 ` Richard Weinberger 0 siblings, 1 reply; 4+ messages in thread From: Artem Bityutskiy @ 2016-07-13 12:48 UTC (permalink / raw) To: Richard Weinberger, Boris Brezillon; +Cc: linux-mtd@lists.infradead.org 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: UBIFS orphans and ro-mounts 2016-07-13 12:48 ` Artem Bityutskiy @ 2016-07-13 12:55 ` Richard Weinberger 2016-07-13 16:21 ` Artem Bityutskiy 0 siblings, 1 reply; 4+ messages in thread From: Richard Weinberger @ 2016-07-13 12:55 UTC (permalink / raw) To: dedekind1, Boris Brezillon; +Cc: linux-mtd@lists.infradead.org Artem, Am 13.07.2016 um 14:48 schrieb Artem Bityutskiy: > 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? :-) Well, I'd say people will understand the on ro-mode free is less than expected since UBIFS had no chance to garbage collect... But I agree that changing the current behavior will confuse users. :-( >> 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. A new mount option is an option, true. That said, the real solution is that u-boot (and other bootloaders) should not mount UBIFS and use static volumes. But currently the opposite is happening on most systems I get my hands on. :( Thanks, //richard -- sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria ATU66964118 - FN 374287y ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: UBIFS orphans and ro-mounts 2016-07-13 12:55 ` Richard Weinberger @ 2016-07-13 16:21 ` Artem Bityutskiy 0 siblings, 0 replies; 4+ messages in thread From: Artem Bityutskiy @ 2016-07-13 16:21 UTC (permalink / raw) To: Richard Weinberger, Boris Brezillon; +Cc: linux-mtd@lists.infradead.org On Wed, 2016-07-13 at 14:55 +0200, Richard Weinberger wrote: > A new mount option is an option, true. > That said, the real solution is that u-boot (and other bootloaders) > should not mount UBIFS and use static volumes. > But currently the opposite is happening on most systems I get my > hands on. :( May be orphans could be handled in background? ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-07-13 16:21 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-07-13 12:29 UBIFS orphans and ro-mounts Richard Weinberger 2016-07-13 12:48 ` Artem Bityutskiy 2016-07-13 12:55 ` Richard Weinberger 2016-07-13 16:21 ` Artem Bityutskiy
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).