All of lore.kernel.org
 help / color / mirror / Atom feed
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Javier Martinez Canillas <javierm@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	Christian Kellner <ckellner@redhat.com>,
	Muhammad Usama Anjum <usama.anjum@collabora.com>,
	Alexander Larsson <alexl@redhat.com>,
	Alberto Ruiz <aruiz@redhat.com>, Peter Jones <pjones@redhat.com>,
	Lennart Poettering <lennart@poettering.net>,
	Colin Walters <walters@verbum.org>,
	Chung-Chiang Cheng <cccheng@synology.com>
Subject: Re: [PATCH v3 2/3] fat: add renameat2 RENAME_EXCHANGE flag support
Date: Tue, 31 May 2022 21:41:45 +0900	[thread overview]
Message-ID: <87czftq3g6.fsf@mail.parknet.co.jp> (raw)
In-Reply-To: <0ca7d264-2522-c820-d26e-19b6685d5016@redhat.com> (Javier Martinez Canillas's message of "Tue, 31 May 2022 14:15:02 +0200")

Javier Martinez Canillas <javierm@redhat.com> writes:

>> Main purpose of me is to consolidate helpers with vfat_rename(), and
>> tweak coding style to use existent fat codes.
>>
>
> Indeed. What do you think of the following plan for v4 ?
>
> 1) Keep patch "fat: add a vfat_rename2() and make existing .rename callback a helper"
>    as the first patch of the series.
> 2) Add a patch #2 with your authorship that adds the helper and use them in the
>    vfat_rename() function.
> 3) Make this patch "fat: add renameat2 RENAME_EXCHANGE flag support" to be patch #3
>    and use the helpers introduced in patch #2.
> 4) Make patch #4 to not only add a test for RENAME_EXCHANGE but also for renameat()
>    and renameat2(..., RENAME_NOREPLACE). That way it will also cover your changes in
>    patch #2.

I don't care much about it because whole is not big (in short, I'm ok
with even one patch), so the point is the patches should be able to
bisect easily if separated.

>>> +	/* update inode version and timestamps */
>>> +	inode_inc_iversion(old_inode);
>>> +	inode_inc_iversion(new_inode);
>> 
>> Why do we need to update iversion of those inodes? I couldn't get intent
>> of this.
>>
>
> To be honest, I wasn't sure about this either but I saw that the implementation
> of RENAME_EXCHANGE in other filesystems did. For example btrfs_rename_exchange().

Ok. If I'm not overlooking, it looks like only btrfs. Please remove
those inode_inc_iversion() for {new,old}_inode.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

  reply	other threads:[~2022-05-31 12:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-26 13:41 [PATCH v3 0/3] fat: add support for the renameat2 RENAME_EXCHANGE flag Javier Martinez Canillas
2022-05-26 13:41 ` [PATCH v3 1/3] fat: add a vfat_rename2() and make existing .rename callback a helper Javier Martinez Canillas
2022-05-26 13:41 ` [PATCH v3 2/3] fat: add renameat2 RENAME_EXCHANGE flag support Javier Martinez Canillas
2022-05-31  9:51   ` OGAWA Hirofumi
2022-05-31 12:15     ` Javier Martinez Canillas
2022-05-31 12:41       ` OGAWA Hirofumi [this message]
2022-05-31 12:46         ` Javier Martinez Canillas
2022-05-26 13:41 ` [PATCH v3 3/3] selftests/filesystems: add a vfat RENAME_EXCHANGE test Javier Martinez Canillas
2022-05-27  6:09   ` Muhammad Usama Anjum

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=87czftq3g6.fsf@mail.parknet.co.jp \
    --to=hirofumi@mail.parknet.co.jp \
    --cc=alexl@redhat.com \
    --cc=aruiz@redhat.com \
    --cc=cccheng@synology.com \
    --cc=ckellner@redhat.com \
    --cc=javierm@redhat.com \
    --cc=lennart@poettering.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pjones@redhat.com \
    --cc=usama.anjum@collabora.com \
    --cc=walters@verbum.org \
    /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.