Hello,

The series adds support for the renameat2 system call RENAME_EXCHANGE flag
(which allows to atomically replace two paths) to the vfat filesystem code.

There are many use cases for this, but we are particularly interested in
making possible for vfat filesystems to be part of OSTree [0] deployments.

Currently OSTree relies on symbolic links to make the deployment updates
an atomic transactional operation. But RENAME_EXCHANGE could be used [1]
to achieve a similar level of robustness when using a vfat filesystem.

Patch #1 is just a preparatory patch to introduce the RENAME_EXCHANGE
support, patch #2 moves some code blocks in vfat_rename() to a set of
helper functions, that can be reused by tvfat_rename_exchange() that's
added by patch #3 and finally patch #4 adds some kselftests to test it.

This is a v4 that addresses issues pointed out in the third version posted:

https://www.spinics.net/lists/kernel/msg4373694.html

[0]: https://github.com/ostreedev/ostree
[1]: https://github.com/ostreedev/ostree/issues/1649

Changes in v4:
- Add new patch from OGAWA Hirofumi to use the helpers in vfat_rename().
- Rebase the patch on top of OGAWA Hirofumi proposed changes.
- Drop iversion increment for old and new file inodes (OGAWA Hirofumi).
- Add Muhammad Usama Anjum Acked-by tag.

Changes in v3:
- Add a .gitignore for the rename_exchange binary (Muhammad Usama Anjum).
- Include $(KHDR_INCLUDES) instead of hardcoding a relative path in Makefile
  (Muhammad Usama Anjum).

Changes in v2:
- Only update the new_dir inode version and timestamps if != old_dir
  (Alex Larsson).
- Add some helper functions to avoid duplicating code (OGAWA Hirofumi).
- Use braces for multi-lines blocks even if are one statement (OGAWA Hirofumi).
- Mention in commit message that the operation is as transactional as possible
  but within the vfat limitations of not having a journal (Colin Walters).
- Call sync to flush the page cache before checking the file contents
  (Alex Larsson).
- Drop RFC prefix since the patches already got some review.

Javier Martinez Canillas (3):
  fat: add a vfat_rename2() and make existing .rename callback a helper
  fat: add renameat2 RENAME_EXCHANGE flag support
  selftests/filesystems: add a vfat RENAME_EXCHANGE test

OGAWA Hirofumi (1):
  fat: factor out reusable code in vfat_rename() as helper functions

 MAINTAINERS                                   |   1 +
 fs/fat/namei_vfat.c                           | 222 +++++++++++++++---
 tools/testing/selftests/Makefile              |   1 +
 .../selftests/filesystems/fat/.gitignore      |   2 +
 .../selftests/filesystems/fat/Makefile        |   7 +
 .../testing/selftests/filesystems/fat/config  |   2 +
 .../filesystems/fat/rename_exchange.c         |  37 +++
 .../filesystems/fat/run_fat_tests.sh          |  82 +++++++
 8 files changed, 315 insertions(+), 39 deletions(-)
 create mode 100644 tools/testing/selftests/filesystems/fat/.gitignore
 create mode 100644 tools/testing/selftests/filesystems/fat/Makefile
 create mode 100644 tools/testing/selftests/filesystems/fat/config
 create mode 100644 tools/testing/selftests/filesystems/fat/rename_exchange.c
 create mode 100755 tools/testing/selftests/filesystems/fat/run_fat_tests.sh

-- 
2.36.1

Hello OGAWA,

On 6/1/22 19:32, Javier Martinez Canillas wrote:
> Hello,
> 
> The series adds support for the renameat2 system call RENAME_EXCHANGE flag
> (which allows to atomically replace two paths) to the vfat filesystem code.
> 
> There are many use cases for this, but we are particularly interested in
> making possible for vfat filesystems to be part of OSTree [0] deployments.
> 
> Currently OSTree relies on symbolic links to make the deployment updates
> an atomic transactional operation. But RENAME_EXCHANGE could be used [1]
> to achieve a similar level of robustness when using a vfat filesystem.
> 
> Patch #1 is just a preparatory patch to introduce the RENAME_EXCHANGE
> support, patch #2 moves some code blocks in vfat_rename() to a set of
> helper functions, that can be reused by tvfat_rename_exchange() that's
> added by patch #3 and finally patch #4 adds some kselftests to test it.
> 

I think that addressed all the issues you pointed out in v3, please let me
know if there's anything else that is needed for this patch series.

Would these be merged by you or should I ping someone else? I'm not
that familiar with how filesystem patches make into the mainline tree.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

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

> Hello OGAWA,
>
> On 6/1/22 19:32, Javier Martinez Canillas wrote:
>> Hello,
>> 
>> The series adds support for the renameat2 system call RENAME_EXCHANGE flag
>> (which allows to atomically replace two paths) to the vfat filesystem code.
>> 
>> There are many use cases for this, but we are particularly interested in
>> making possible for vfat filesystems to be part of OSTree [0] deployments.
>> 
>> Currently OSTree relies on symbolic links to make the deployment updates
>> an atomic transactional operation. But RENAME_EXCHANGE could be used [1]
>> to achieve a similar level of robustness when using a vfat filesystem.
>> 
>> Patch #1 is just a preparatory patch to introduce the RENAME_EXCHANGE
>> support, patch #2 moves some code blocks in vfat_rename() to a set of
>> helper functions, that can be reused by tvfat_rename_exchange() that's
>> added by patch #3 and finally patch #4 adds some kselftests to test it.
>> 
>
> I think that addressed all the issues you pointed out in v3, please let me
> know if there's anything else that is needed for this patch series.
>
> Would these be merged by you or should I ping someone else? I'm not
> that familiar with how filesystem patches make into the mainline tree.

Sorry, it is just the my issue. I was traveling latest week, so is not
reviewing yet. I'll do soon.

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

On 6/8/22 11:42, OGAWA Hirofumi wrote:
> Javier Martinez Canillas <javierm@redhat.com> writes:
> 
>> Hello OGAWA,
>>
>> On 6/1/22 19:32, Javier Martinez Canillas wrote:
>>> Hello,
>>>
>>> The series adds support for the renameat2 system call RENAME_EXCHANGE flag
>>> (which allows to atomically replace two paths) to the vfat filesystem code.
>>>
>>> There are many use cases for this, but we are particularly interested in
>>> making possible for vfat filesystems to be part of OSTree [0] deployments.
>>>
>>> Currently OSTree relies on symbolic links to make the deployment updates
>>> an atomic transactional operation. But RENAME_EXCHANGE could be used [1]
>>> to achieve a similar level of robustness when using a vfat filesystem.
>>>
>>> Patch #1 is just a preparatory patch to introduce the RENAME_EXCHANGE
>>> support, patch #2 moves some code blocks in vfat_rename() to a set of
>>> helper functions, that can be reused by tvfat_rename_exchange() that's
>>> added by patch #3 and finally patch #4 adds some kselftests to test it.
>>>
>>
>> I think that addressed all the issues you pointed out in v3, please let me
>> know if there's anything else that is needed for this patch series.
>>
>> Would these be merged by you or should I ping someone else? I'm not
>> that familiar with how filesystem patches make into the mainline tree.
> 
> Sorry, it is just the my issue. I was traveling latest week, so is not
> reviewing yet. I'll do soon.
> 

Sure, there's no rush. I just wanted to confirm that. Thanks a lot!

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat