[PATCH] kernel: force atomic renames in ubifs

[Richard Weinberger]

Rafał,

----- Ursprüngliche Mail -----
> Von: "Rafał Miłecki" <zajec5 at gmail.com>
> An: "OpenWrt Development List" <openwrt-devel at lists.openwrt.org>
> CC: "Koen Vandeputte" <koen.vandeputte at ncentric.com>, "richard" <richard at nod.at>, "Rafał Miłecki" <rafal at milecki.pl>
> Gesendet: Dienstag, 1. März 2022 20:13:29
> Betreff: [PATCH] kernel: force atomic renames in ubifs

> From: Rafał Miłecki <rafal at milecki.pl>
> 
> This deals with user-spaces apps that don't handle all syncing
> correctly. It prevents user ending up with an empty file.
> 
> Signed-off-by: Rafał Miłecki <rafal at milecki.pl>
> ---
> .../510-ubifs-force-atomic-renames.patch      | 46 +++++++++++++++++++
> .../510-ubifs-force-atomic-renames.patch      | 46 +++++++++++++++++++
> 2 files changed, 92 insertions(+)
> create mode 100644
> target/linux/generic/pending-5.10/510-ubifs-force-atomic-renames.patch
> create mode 100644
> target/linux/generic/pending-5.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 0000000000..80f5f1b910
> --- /dev/null
> +++ b/target/linux/generic/pending-5.10/510-ubifs-force-atomic-renames.patch
> @@ -0,0 +1,46 @@
> +From: Richard Weinberger <richard at nod.at>
> +Date: Mon, 28 Feb 2022 16:07:41 +0100
> +Subject: [PATCH] ubifs: force atomic renames
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +Before actual rename make sure that the old inode data has been flash
> +written. This is similar to what other filesystems do and workarounds
> +bugs in some user-space apps.
> +
> +With this change updating file using tmpfile & rename() will never
> +result in losing all content e.g. on power cut.

Please slow down a bit. :-)
The commit message is not written by me and also not entirely correct.

The patch is not about making rename atomic. rename is already atomic
on UBIFS.
It is about syncing in flight pages when a file is overwritten by rename.

While I plan to upstream this change it still needs more testing.
I'm also not sure about the overhead it causes. Flushing the write buffers
can cause more garbage collection and may trigger write amplification.

Thanks,
//richard