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

["Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Hi Jens,

Ping^2!

Cheers,

Michael


On 3 September 2017 at 02:45, Michael Kerrisk (man-pages)
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 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
>>
>>
>>
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html