All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hyunchul Lee <hyc.lee@gmail.com>
To: Richard Weinberger <richard@nod.at>
Cc: david@sigma-star.at, bfields@redhat.com, dedekind1@gmail.com,
	rockdotlee@gmail.com, adrian.hunter@intel.com,
	linux-kernel@vger.kernel.org, kernel-team@lge.com,
	linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org,
	adilger.kernel@dilger.ca, akpm@linux-foundation.org,
	marcus.folkesson@gmail.com, leon.pollak@gmail.com
Subject: Re: [PATCH 4/6] ubifs: Maintain a parent pointer
Date: Tue, 23 May 2017 08:50:49 +0900	[thread overview]
Message-ID: <20170522235049.GA22083@sebu> (raw)
In-Reply-To: <71c6f44e-ad49-d8b0-8e1c-cada1769a3be@nod.at>

Hi Richard,

On Mon, May 22, 2017 at 10:45:08AM +0200, Richard Weinberger wrote:
> Hyunchul,
> 
> Am 22.05.2017 um 06:30 schrieb Hyunchul Lee:
> >> +	if (move)
> >> +		old_inode_ui->parent_inum = new_dir->i_ino;
> >> +
> >>  	err = ubifs_jnl_rename(c, old_dir, old_inode, &old_nm, new_dir,
> >>  			       new_inode, &new_nm, whiteout, sync);
> > 
> > I think that old_inode_ui->parent_inum could point old_dir, even though old_inode
> > is a child of new_dir. this could happen that there is power-cut before
> > old_inode is synced. so I guess that old_inode is needed to be written with
> > rename's node group in ubifs_jnl_rename. is it right?
> 
> I assumed that the journal does this already because we change old_inode->i_ctime
> in this function too.
> But checking the code showed the opposite.
> So, if we face a power-cut the rename can succeed but we lose the ctime change.
> 
> This needs to be addressed before we can add the parent pointer.

Is writing old_inode->i_ctime required? I guess that it is needed only when 
IS_SYNC(old_inode) is true, otherwise we don't need to guarantee that ctime
is synced.

> 
> Thanks,
> //richard
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

-- 

Thanks,
Hyunchul

  reply	other threads:[~2017-05-22 23:51 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-21 20:20 [PATCH 0/6] UBIFS NFS export support v2 Richard Weinberger
2017-05-21 20:20 ` [PATCH 1/6] ext4: Move is_32bit_api() to generic code Richard Weinberger
2017-05-21 20:20   ` Richard Weinberger
2017-05-23  8:36   ` Christoph Hellwig
2017-05-23  8:36     ` Christoph Hellwig
2017-05-21 20:20 ` [PATCH 2/6] ubifs: Provide a custom llseek for directories Richard Weinberger
2017-05-21 20:20 ` [PATCH 3/6] ubifs: Use 64bit readdir cookies Richard Weinberger
2017-05-21 20:20 ` [PATCH 4/6] ubifs: Maintain a parent pointer Richard Weinberger
2017-05-22  4:30   ` Hyunchul Lee
2017-05-22  8:45     ` Richard Weinberger
2017-05-22 23:50       ` Hyunchul Lee [this message]
2017-05-23  7:16         ` Richard Weinberger
2017-05-23  8:37   ` Christoph Hellwig
2017-05-23  8:42     ` Richard Weinberger
2017-05-21 20:20 ` [PATCH 5/6] ubifs: Implement export_operations Richard Weinberger
2017-05-23  8:39   ` Christoph Hellwig
2017-05-23  8:39     ` Christoph Hellwig
2017-05-23  8:41     ` Richard Weinberger
2017-05-23  8:48       ` Christoph Hellwig
2017-05-23  8:50         ` Richard Weinberger
2017-05-21 20:20 ` [PATCH 6/6] ubifs: Wire up NFS support Richard Weinberger
  -- strict thread matches above, loose matches on Subject: below --
2016-12-01 22:02 [PATCH 0/6] UBIFS NFS export support Richard Weinberger
2016-12-01 22:02 ` [PATCH 4/6] ubifs: Maintain a parent pointer Richard Weinberger
2016-12-02  9:28   ` Marcus Folkesson
2016-12-02 10:36     ` Richard Weinberger
2017-04-28  8:31   ` Hyunchul Lee
2017-04-28  9:09     ` Richard Weinberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170522235049.GA22083@sebu \
    --to=hyc.lee@gmail.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=adrian.hunter@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bfields@redhat.com \
    --cc=david@sigma-star.at \
    --cc=dedekind1@gmail.com \
    --cc=kernel-team@lge.com \
    --cc=leon.pollak@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marcus.folkesson@gmail.com \
    --cc=richard@nod.at \
    --cc=rockdotlee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.