Currently creating tmpfiles on Linux can be problematic because the
tmpfile is not created and opened at the same time (vfs_tmpfile calls
into the fs, then later vfs_open is called to open the tmpfile). For
some filesystems it would be more natural to create and open the
tmpfile as one operation (because the action of creating the file on
some filesystems returns an open handle, so closing it then reopening
it would cause the tmpfile to be deleted).
I would like to discuss whether the function do_tmpfile (which creates
and then opens the tmpfile) could have an option for a filesystem to
do this as one operation which would allow it to be more atomic and
allow it to work on a wider variety of filesystems.
--
Thanks,
Steve
On Thu, 24 Feb 2022 at 06:33, Steve French <[email protected]> wrote:
>
> Currently creating tmpfiles on Linux can be problematic because the
> tmpfile is not created and opened at the same time (vfs_tmpfile calls
> into the fs, then later vfs_open is called to open the tmpfile). For
> some filesystems it would be more natural to create and open the
> tmpfile as one operation (because the action of creating the file on
> some filesystems returns an open handle, so closing it then reopening
> it would cause the tmpfile to be deleted).
>
> I would like to discuss whether the function do_tmpfile (which creates
> and then opens the tmpfile) could have an option for a filesystem to
> do this as one operation which would allow it to be more atomic and
> allow it to work on a wider variety of filesystems.
A related thread:
https://lore.kernel.org/all/[email protected]/#r
There was no conclusion in the end. Not sure how hacky it would be to
store the open file in the inode...
Thanks,
Miklos
> On May 3, 2022, at 2:52 PM, Miklos Szeredi <[email protected]> wrote:
>
> On Thu, 24 Feb 2022 at 06:33, Steve French <[email protected]> wrote:
>>
>> Currently creating tmpfiles on Linux can be problematic because the
>> tmpfile is not created and opened at the same time (vfs_tmpfile calls
>> into the fs, then later vfs_open is called to open the tmpfile). For
>> some filesystems it would be more natural to create and open the
>> tmpfile as one operation (because the action of creating the file on
>> some filesystems returns an open handle, so closing it then reopening
>> it would cause the tmpfile to be deleted).
>>
>> I would like to discuss whether the function do_tmpfile (which creates
>> and then opens the tmpfile) could have an option for a filesystem to
>> do this as one operation which would allow it to be more atomic and
>> allow it to work on a wider variety of filesystems.
>
> A related thread:
>
> https://lore.kernel.org/all/[email protected]/#r
>
> There was no conclusion in the end. Not sure how hacky it would be to
> store the open file in the inode...
I just proposed adding a VFS API to make open/create atomic.
See 8/8 in this thread:
https://lore.kernel.org/linux-nfs/[email protected]/T/#m505a59ad4e4ed1413ffc055a088de3182fb50bb4
It adds a sibling API to dentry_open(). I didn't have
O_TMPFILE in mind when I created this API.
--
Chuck Lever