linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  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).