lkml.org 
[lkml]   [2022]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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

    \
     
     \ /
      Last update: 2022-01-10 11:14    [W:4.325 / U:0.248 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site