From: Richard Weinberger <richard@nod.at>
To: "Bean Huo (beanhuo)" <beanhuo@micron.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: UBIFS file has zeroes at the end after an unclean reboot
Date: Mon, 23 Jul 2018 13:22:08 +0200 [thread overview]
Message-ID: <1929018.rLX3MmPisr@blindfold> (raw)
In-Reply-To: <8f54ca9aee0947d49e7e99dd11f33a74@SIWEX5A.sing.micron.com>
Bean,
Am Montag, 23. Juli 2018, 13:12:09 CEST schrieb Bean Huo (beanhuo):
> Hi, Richard
> Do you have good suggestions about how to prevent this condiciton: http://www.linux-mtd.infradead.org/faq/ubifs.html#L_end_hole ?
Well, I'd start with making sure that userspaces does the right thing(tm) and to
be very sure what kind of problem the user is facing.
Did you verify whether the affected program is using fsync/fdatasync?
Does your kernel include
commit 1b7fc2c0069f3864a3dda15430b7aded31c0bfcc
Author: Rafał Miłecki <rafal@milecki.pl>
Date: Tue Sep 20 10:36:15 2016 +0200
ubifs: Use dirty_writeback_interval value for wbuf timer
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>
Signed-off-by: Richard Weinberger <richard@nod.at>
?
Thanks,
//richard
next prev parent reply other threads:[~2018-07-23 11:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-23 11:12 UBIFS file has zeroes at the end after an unclean reboot Bean Huo (beanhuo)
2018-07-23 11:22 ` Richard Weinberger [this message]
2018-07-23 13:25 ` [EXT] " Bean Huo (beanhuo)
2018-07-23 13:57 ` Richard Weinberger
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=1929018.rLX3MmPisr@blindfold \
--to=richard@nod.at \
--cc=beanhuo@micron.com \
--cc=linux-mtd@lists.infradead.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).