| Message ID | 20220601173204.1372569-1-javierm@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | fat: add support for the renameat2 RENAME_EXCHANGE flag | expand |
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.
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.
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!