Messages in this thread | | | Date | Mon, 10 Jan 2022 11:14:03 +0100 (CET) | From | Richard Weinberger <> | Subject | Re: [PATCH v6 05/15] ubifs: Rename whiteout atomically |
| |
----- Ursprüngliche Mail ----- > Von: "chengzhihao1" <chengzhihao1@huawei.com> > An: "richard" <richard@nod.at> > CC: "Miquel Raynal" <miquel.raynal@bootlin.com>, "Vignesh Raghavendra" <vigneshr@ti.com>, "mcoquelin stm32" > <mcoquelin.stm32@gmail.com>, "kirill shutemov" <kirill.shutemov@linux.intel.com>, "Sascha Hauer" > <s.hauer@pengutronix.de>, "linux-mtd" <linux-mtd@lists.infradead.org>, "linux-kernel" <linux-kernel@vger.kernel.org> > Gesendet: Montag, 10. Januar 2022 10:35:02 > Betreff: Re: [PATCH v6 05/15] ubifs: Rename whiteout atomically
> Hi, Richard >> >> 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. >> > > The whiteout inode is clean after creation from create_whiteout(), and > it can't be marked dirty until ubifs_jnl_rename() finished. So, I think > there is no chance for whiteout being written on disk. Then, > 'ubifs_assert(c, !whiteout_ui->dirty)' never fails in ubifs_jnl_rename() > during my local stress tests. You may add some delay executions after > whiteout creation to make sure that whiteout won't be written back > before ubifs_jnl_rename().
From UBIFS point of view I fully agree with you. I'm just a little puzzled why other filesystems use the tmpfile approach. My fear is that VFS can do things to the inode we don't have in mind right now.
Thanks, //richard
| |