Re: [PATCH] base-files: call "sync" after initial setup

- Ursprüngliche Mail - > Von: "Koen Vandeputte" >>> Signed-off-by: Rafał Miłecki >> >> Acked-by: Hauke Mehrtens >> >> This is not the best solution as you said but a simple one. >> >> How do we handle the situation in the first boot when the overlay file >> system is not ready yet and we

Re: [PATCH] kernel: force atomic renames in ubifs

4/510-ubifs-force-atomic-renames.patch > > diff --git > a/target/linux/generic/pending-5.10/510-ubifs-force-atomic-renames.patch > b/target/linux/generic/pending-5.10/510-ubifs-force-atomic-renames.patch > new file mode 100644 > index 00..80f5f1b910 > --- /dev/null > ++

Re: ubifs: handling dirty data (writing back) + power cuts

Rafał, - Ursprüngliche Mail - > Von: "Rafał Miłecki" > On 25.02.2022 15:17, Rafał Miłecki wrote: >> My actual problem is related to ubifs behaviour for power cuts happening >> between 5 and 35 seconds after saving a file: >> date > /mount/ubifs/test.txt && sleep 15 && echo CUT POWER *NOW*

Re: [OpenWrt-Devel] [PATCH 1/2] imx6: bootscript: enable UBI fastmap support

Koen, - Ursprüngliche Mail - > > I'm also seeing this warning: > > > [    0.00] Kernel command line: console=ttymxc1,115200 ubi0:ubi > ubi.mtd=2 rootfstype=squashfs,ubifs ubi.fm_autoconvert=1 > > [    2.356304] ubi0: default fastmap pool size: 95 > [    2.360850] ubi0: default fast

Re: [OpenWrt-Devel] [PATCH 1/2] imx6: bootscript: enable UBI fastmap support

Koen, - Ursprüngliche Mail - >> +# enable UBI fastmap support >> +setenv bootargs "${bootargs} ubi.fm_autoconvert=1" >> else >> echo "Booting from block device ${bootdev}..." >> setenv fsload "${fs}load ${dtype} ${disk}:1" > > Hi Tim, > > Shouldn't this patch also ena

Re: [OpenWrt-Devel] [PATCH 6/8 v3] ubifs: Use dirty_writeback_interval value for wbuf timer

;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:

Re: [OpenWrt-Devel] Regression in handling power cuts since 3a1e819b4e80 ("ovl: store file handle of lower inode on copy up")

Rafał, Am Montag, 22. Oktober 2018, 17:34:44 CEST schrieb Rafał Miłecki: > Then I took a close look at ovl_copy_up_locked() and it seems above > info isn't accurate. It seems to me that setxattr() happens between > fsync and link. I modified my C app to follow that order (open, write, > fsync, set

Re: [OpenWrt-Devel] Regression in handling power cuts since 3a1e819b4e80 ("ovl: store file handle of lower inode on copy up")

Am Montag, 22. Oktober 2018, 09:14:08 CEST schrieb Rafał Miłecki: > On Fri, 19 Oct 2018 at 14:31, Rafał Miłecki wrote: > > Since OpenWrt switch from kernel 4.9 to 4.14 users started randomly > > reporting file system corruptions. OpenWrt uses overlay(fs) with > > squashfs as lowerdir and ubifs as

Re: [OpenWrt-Devel] Regression in handling power cuts since 3a1e819b4e80 ("ovl: store file handle of lower inode on copy up")

Am Freitag, 19. Oktober 2018, 23:28:33 CEST schrieb Rafał Miłecki: > On Fri, 19 Oct 2018 at 16:59, Richard Weinberger wrote: > > Am Freitag, 19. Oktober 2018, 16:45:53 CEST schrieb Richard Weinberger: > > > Well, I fear it uncovers a problem in UBIFS. We had already problems wit

Re: [OpenWrt-Devel] Regression in handling power cuts since 3a1e819b4e80 ("ovl: store file handle of lower inode on copy up")

Am Freitag, 19. Oktober 2018, 18:18:05 CEST schrieb Rafał Miłecki: > > Do you have something also I can test? > > A C reproducer? An xfstest case? > > I don't. I may try writing one with info provided my Amir, but I'm not > experienced with such things, won't be trivial for me. Next week I'm in E

Re: [OpenWrt-Devel] Regression in handling power cuts since 3a1e819b4e80 ("ovl: store file handle of lower inode on copy up")

Am Freitag, 19. Oktober 2018, 16:45:53 CEST schrieb Richard Weinberger: > Well, I fear it uncovers a problem in UBIFS. We had already problems with > overlayfs. > Did you bisect the problem and you are sure that the said commit is the first > bad commit? Another thing, UBIFS h

Re: [OpenWrt-Devel] Regression in handling power cuts since 3a1e819b4e80 ("ovl: store file handle of lower inode on copy up")

Rafał, - Ursprüngliche Mail - > Von: "Rafał Miłecki" > An: "Amir Goldstein" , "Miklos Szeredi" > , linux-unio...@vger.kernel.org, > linux-fsde...@vger.kernel.org, "richard" , "Artem Bityutskiy" > , "Adrian Hunter" > , linux-...@lists.infradead.org, "Russell Senior" > , "OpenWrt > Devel

Re: [OpenWrt-Devel] UBIFS issues within kernel 4.14.69?

Am Sonntag, 16. September 2018, 22:11:07 CEST schrieb Koen Vandeputte: > Hi Richard, > > Apologies for the late reply. > It was a busy weekend with the kids .. > > I'm very pleased to read you already have a good idea of what is going > on here. > > Can I conclude you will provide a patch upstr

Re: [OpenWrt-Devel] UBIFS issues within kernel 4.14.69?

Koen, Am Samstag, 15. September 2018, 09:13:09 CEST schrieb Richard Weinberger: > Koen, > > Am Dienstag, 11. September 2018, 16:26:34 CEST schrieb Koen Vandeputte: > > > > On 2018-09-11 15:46, Koen Vandeputte wrote: > > > Hi Richard, > > ... > > &

Re: [OpenWrt-Devel] UBIFS issues within kernel 4.14.69?

Koen, Am Dienstag, 11. September 2018, 16:26:34 CEST schrieb Koen Vandeputte: > > On 2018-09-11 15:46, Koen Vandeputte wrote: > > Hi Richard, > ... > > > I'm only seeing these issues on UBIFS enabled volumes. > > > > It seems it's related to one of your 5 commits, but I'm still in the > > proce