Re: man page update (fcntl(2) new set/get write hints)

Michael Kerrisk (man-pages)
2017-09-03T00:45:13Z

Hi Jens,

Ping!

Cheers,

Michael

On 08/28/2017 11:16 PM, Michael Kerrisk (man-pages) wrote:
> On 08/28/2017 10:15 PM, Jens Axboe wrote:
>> On 08/28/2017 01:19 PM, Michael Kerrisk (man-pages) wrote:
>>> Hi Jens,
>>>
>>> On 08/25/2017 10:55 PM, Jens Axboe wrote:
>>>> On 08/25/2017 02:51 PM, Michael Kerrisk (man-pages) wrote:
>>>>>>>>> Do you mean here "file descriptor" or "file description (i.e., the
>>>>>>>>> open file handle)? Maybe you mean the former, but I want to confirm.
>>>>>>>>
>>>>>>>> I do mean file descriptor.
>>>>>>>
>>>>>>> So, what are the semantics if a file descriptor is duplicated using
>>>>>>> dup(2) or similar? If I understand correctly, then the write lifetime
>>>>>>> hint has no effect for the new file descriptor, right?
>>>>>>
>>>>>> If it's dup(2)'ed, then the new file descriptor will refer to the same
>>>>>> hints as the previous. See attached test file.
>>>>>
>>>>> But then isn't this exactly the point I asked about: are the hints
>>>>> private to a file descriptor or are they associated with the open file
>>>>> description (open file table entry, "struct file")? You said "I do
>>>>> mean file descriptor", but actually I understand what you just said
>>>>> now as "hints are associated with the open file description, which may
>>>>> be referred to by multiple duplicated file descriptors". Can you
>>>>> clarify?
>>>>
>>>> You are right, I misunderstood your original question. They do follow
>>>> the file description. So the dup'ed one will return the same as the
>>>> original, even if the hints on the original fd get modified. That is the
>>>> expected behavior.
>>>
>>> So, I am still confused. I was wondering whether the hints are
>>> associated with the open file description (OFD), rather than the
>>> file descriptor. You said yes, then say that the dup'ed file
>>> descriptor will have the same hints even if the hints on the
>>> original file descriptor are modified. To me that sounds like:
>>> the hints are associated with the file descriptor, and not the
>>> OFD, and during dup(2) the hints are *copied* to the the new
>>> file descriptor, with the result that after the dup(2) the hints
>>> can be modified independently for the two file descriptors.
>>>
>>> Can you clarify please?
>>
>> No, that's not how it behaves. If you dup(2) the file descriptor, then
>> the dup'ed descriptor will return the same hint as was set on the
>> original. If you change/clear the hint on the original, the dup'ed
>> descriptor will now return the new hint.
>
> Okay -- thanks. I'd misunderstood your earlier words. Okay, I've
> hacked this text to arrive at new text below. Could you please check
> it? Also, there are some details that are still missing. Could you take
> a look at the questions below please.
>
> [[[
> File read/write hints
> Write lifetime hints can be used to inform the kernel about the
> relative expected lifetime of writes on a given inode or via a
> particular open file description. (See open(2) for an explanation
> of open file desriptions.) In this context, the term "write life‐
> time" means the expected time the data will live on media, before
> being overwritten or erased.
>
> An application may use the different hint values specified below
> to separate writes into different write classes, so that multiple
> users or applications running on a single storage back-end can
> aggregate their I/O patterns in a consistent manner. However,
> there are no functional semantics implied by these flags, and dif‐
> ferent I/O classes can use the write lifetime hints in arbitrary
> ways, so long as the hints are used consistently.
>
> QUESTIONS:
> * What are write classes?
> * What are I/O classes?
> * What is the purpose of using read/write hints? I assume it's a
> performance point, but the text is not explicit about that.
> * You variously wrote "read/write hints" and "write hints". Let's make
> it consistent. Which is the preferred term?
>
> The following operations can be applied to the file descriptor,
> fd:
>
> F_GET_RW_HINT (uint64_t *; since Linux 4.13)
> Returns the value of the read/write hint associated with
> the underlying inode referred to by fd.
>
> F_SET_RW_HINT (uint64_t *; since Linux 4.13)
> Sets the read/write hint value associated with the underly‐
> ing inode referred to by fd.
>
> F_GET_FILE_RW_HINT (uint64_t *; since Linux 4.13)
> Returns the value of the read/write hint associated with
> the open file description referred to by fd.
>
> F_SET_FILE_RW_HINT (uint64_t *; since Linux 4.13)
> Sets the read/write hint value associated with the open
> file description referred to by fd.
>
> If an open file description has not been assigned a read/write
> hint, then it shall use the value assigned to the inode, if any.
>
> The following read/write hints are valid since Linux 4.13:
>
> RWH_WRITE_LIFE_NOT_SET
> No specific hint has been set. This is the default value.
>
> RWH_WRITE_LIFE_NONE
> No specific write lifetime is associated with this file or
> inode.
>
> RWH_WRITE_LIFE_SHORT
> Data written to this inode or via this open file descrip‐
> tion is expected to have a short lifetime.
>
> RWH_WRITE_LIFE_MEDIUM
> Data written to this inode or via this open file descrip‐
> tion is expected to have a lifetime longer than data writ‐
> ten with RWH_WRITE_LIFE_SHORT.
>
> RWH_WRITE_LIFE_LONG
> Data written to this inode or via this open file descrip‐
> tion is expected to have a lifetime longer than data writ‐
> ten with RWH_WRITE_LIFE_MEDIUM.
>
> RWH_WRITE_LIFE_EXTREME
> Data written to this inode or via this open file descrip‐
> tion is expected to have a lifetime longer than data writ‐
> ten with RWH_WRITE_LIFE_LONG.
>
> All the write-specific hints are relative to each other, and no
> individual absolute meaning should be attributed to them.
> ]]]
>
> Cheers,
>
> Michael