Clayton is out currently, but I can comment on what he had told me. On Thu, May 16, 2019 at 6:05 AM Richard Weinberger <richard.weinberger@xxxxxxxxx> wrote: > > On Mon, May 6, 2019 at 12:22 AM Richard Weinberger > <richard.weinberger@xxxxxxxxx> wrote: > > > > On Fri, May 3, 2019 at 10:14 PM Clayton Shotwell > > <clayton.shotwell@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > Need to ensure the underlying flash does not cache anything even though > > > the file system thinks it's synced back. > > > > > > Signed-off-by: Clayton Shotwell <clayton.shotwell@xxxxxxxxxxxxxxxxxxx> > > > --- > > > fs/jffs2/super.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c > > > index 05d892c..4341565 100644 > > > --- a/fs/jffs2/super.c > > > +++ b/fs/jffs2/super.c > > > @@ -111,6 +111,7 @@ static int jffs2_sync_fs(struct super_block *sb, int wait) > > > mutex_lock(&c->alloc_sem); > > > jffs2_flush_wbuf_pad(c); > > > mutex_unlock(&c->alloc_sem); > > > + mtd_sync(c->mtd); > > > > This needs a more detailed explanation. > > mtd_sync() is not cheap, so you make syncfs() more expensive. > > > > Please explain what failure you are facing without mtd_sync(). > > jffs2 is supposed to recover from a power failure at any time, just like ubifs. The system exhibiting problems runs jffs2 on a gluebi device. Our software sync()'s the jffs2 at certain points so that it's safe if power is cut. The jffs2 always recovers the filesystem after power cut, but sometimes data written before the sync() call gets lost. These patches attempt to solve this problem by 1) calling _sync() on the underlying mtd device after writing to flush any buffers in the mtd, and 2) adding a _sync() callback to gluebi so that if something syncs the mtd device, we sync any blocks associated with it. > > Ping? > > -- > Thanks, > //richard ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/