[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1985807262.244880.1641762859448.JavaMail.zimbra@nod.at>
Date: Sun, 9 Jan 2022 22:14:19 +0100 (CET)
From: Richard Weinberger <richard@....at>
To: chengzhihao1 <chengzhihao1@...wei.com>
Cc: Miquel Raynal <miquel.raynal@...tlin.com>,
Vignesh Raghavendra <vigneshr@...com>,
mcoquelin stm32 <mcoquelin.stm32@...il.com>,
kirill shutemov <kirill.shutemov@...ux.intel.com>,
Sascha Hauer <s.hauer@...gutronix.de>,
linux-mtd <linux-mtd@...ts.infradead.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 05/15] ubifs: Rename whiteout atomically
----- Ursprüngliche Mail -----
> Von: "chengzhihao1" <chengzhihao1@...wei.com>
> An: "richard" <richard@....at>, "Miquel Raynal" <miquel.raynal@...tlin.com>, "Vignesh Raghavendra" <vigneshr@...com>,
> "mcoquelin stm32" <mcoquelin.stm32@...il.com>, "kirill shutemov" <kirill.shutemov@...ux.intel.com>, "Sascha Hauer"
> <s.hauer@...gutronix.de>
> CC: "linux-mtd" <linux-mtd@...ts.infradead.org>, "linux-kernel" <linux-kernel@...r.kernel.org>
> Gesendet: Montag, 27. Dezember 2021 04:22:36
> Betreff: [PATCH v6 05/15] ubifs: Rename whiteout atomically
> Currently, rename whiteout has 3 steps:
> 1. create tmpfile(which associates old dentry to tmpfile inode) for
> whiteout, and store tmpfile to disk
> 2. link whiteout, associate whiteout inode to old dentry agagin and
> store old dentry, old inode, new dentry on disk
> 3. writeback dirty whiteout inode to disk
>
> Suddenly power-cut or error occurring(eg. ENOSPC returned by budget,
> memory allocation failure) during above steps may cause kinds of problems:
> Problem 1: ENOSPC returned by whiteout space budget (before step 2),
> old dentry will disappear after rename syscall, whiteout file
> cannot be found either.
>
> ls dir // we get file, whiteout
> rename(dir/file, dir/whiteout, REANME_WHITEOUT)
> ENOSPC = ubifs_budget_space(&wht_req) // return
> ls dir // empty (no file, no whiteout)
> Problem 2: Power-cut happens before step 3, whiteout inode with 'nlink=1'
> is not stored on disk, whiteout dentry(old dentry) is written
> on disk, whiteout file is lost on next mount (We get "dead
> directory entry" after executing 'ls -l' on whiteout file).
>
> Now, we use following 3 steps to finish rename whiteout:
> 1. create an in-mem inode with 'nlink = 1' as whiteout
> 2. ubifs_jnl_rename (Write on disk to finish associating old dentry to
> whiteout inode, associating new dentry with old inode)
> 3. iput(whiteout)
>
> Rely writing in-mem inode on disk by ubifs_jnl_rename() to finish rename
> whiteout, which avoids middle disk state caused by suddenly power-cut
> and error occurring.
How do you make sure the the whiteout is never written to disk (by writeback) before ubifs_jnl_rename() linked
it? That's the reason why other filesystems use the tmpfile mechanism for whiteouts too.
Thanks,
//richard
Powered by blists - more mailing lists