On 06/27/2017 08:42 AM, Christoph Hellwig wrote:
> The API looks ok, but the code could use some cleanups. What do
> you think about the incremental patch below:
>
> It refactors various manipulations, and stores the write hint right
> in the iocb as there is a 4 byte hole (this will need some
On Tue, Jun 27, 2017 at 09:09:48AM -0600, Jens Axboe wrote:
> On 06/27/2017 08:42 AM, Christoph Hellwig wrote:
> > The API looks ok, but the code could use some cleanups. What do
> > you think about the incremental patch below:
> >
> > It refactors various manipulations, and stores the write
On 06/27/2017 09:16 AM, Christoph Hellwig wrote:
> On Tue, Jun 27, 2017 at 09:09:48AM -0600, Jens Axboe wrote:
>> On 06/27/2017 08:42 AM, Christoph Hellwig wrote:
>>> The API looks ok, but the code could use some cleanups. What do
>>> you think about the incremental patch below:
>>>
>>> It
On 06/27/2017 08:57 AM, Christoph Hellwig wrote:
> On Tue, Jun 27, 2017 at 08:55:02AM -0600, Jens Axboe wrote:
>> BTW, that patch does not look like an incremental patch, what's
>> this against?
>
> The patch I'm replying to, without the other ones.
Looks like a replacement patch, not
On Tue, Jun 27, 2017 at 08:55:02AM -0600, Jens Axboe wrote:
> BTW, that patch does not look like an incremental patch, what's
> this against?
The patch I'm replying to, without the other ones.
On 06/27/2017 08:42 AM, Christoph Hellwig wrote:
> The API looks ok, but the code could use some cleanups. What do
> you think about the incremental patch below:
>
> It refactors various manipulations, and stores the write hint right
> in the iocb as there is a 4 byte hole (this will need some
On Tue, Jun 27, 2017 at 07:42:55AM -0700, Christoph Hellwig wrote:
> The API looks ok, but the code could use some cleanups. What do
> you think about the incremental patch below:
>
> It refactors various manipulations, and stores the write hint right
> in the iocb as there is a 4 byte hole
The API looks ok, but the code could use some cleanups. What do
you think about the incremental patch below:
It refactors various manipulations, and stores the write hint right
in the iocb as there is a 4 byte hole (this will need some minor
adjustments in the next patches):
diff --git
On 06/26/2017 10:09 AM, Darrick J. Wong wrote:
> On Mon, Jun 26, 2017 at 07:55:27AM -0600, Jens Axboe wrote:
>> On 06/26/2017 03:51 AM, Christoph Hellwig wrote:
>>> Please document the userspace API (added linux-api and linux-man
>>> to CC for sugestions), especially including the odd effects of
On Mon, Jun 26, 2017 at 07:55:27AM -0600, Jens Axboe wrote:
> On 06/26/2017 03:51 AM, Christoph Hellwig wrote:
> > Please document the userspace API (added linux-api and linux-man
> > to CC for sugestions), especially including the odd effects of the
> > per-inode settings.
>
> Of course, I'll
Define a set of write life time hints:
RWH_WRITE_LIFE_NOT_SET No hint information set
RWH_WRITE_LIFE_NONE No hints about write life time
RWH_WRITE_LIFE_SHORTData written has a short life time
RWH_WRITE_LIFE_MEDIUM Data written has a medium life time
RWH_WRITE_LIFE_LONG Data written
On 06/26/2017 03:51 AM, Christoph Hellwig wrote:
> Please document the userspace API (added linux-api and linux-man
> to CC for sugestions), especially including the odd effects of the
> per-inode settings.
Of course, I'll send in a diff for the fcntl(2) man page.
> Also I would highly recommend
Please document the userspace API (added linux-api and linux-man
to CC for sugestions), especially including the odd effects of the
per-inode settings.
Also I would highly recommend to use different fcntl commands
for the file vs inode hints to avoid any strange behavior.
Define a set of write life time hints:
RWH_WRITE_LIFE_NONE No hints about write life time
RWH_WRITE_LIFE_SHORTData written has a short life time
RWH_WRITE_LIFE_MEDIUM Data written has a medium life time
RWH_WRITE_LIFE_LONG Data written has a long life time
RWH_WRITE_LIFE_EXTREME
On 06/20/2017 05:09 PM, Bart Van Assche wrote:
> On Mon, 2017-06-19 at 11:04 -0600, Jens Axboe wrote:
>> +static long fcntl_rw_hint(struct file *file, unsigned int cmd,
>> + u64 __user *ptr)
>> +{
>> +struct inode *inode = file_inode(file);
>> +long ret = 0;
>> +
On Mon, 2017-06-19 at 11:04 -0600, Jens Axboe wrote:
> +static long fcntl_rw_hint(struct file *file, unsigned int cmd,
> + u64 __user *ptr)
> +{
> + struct inode *inode = file_inode(file);
> + long ret = 0;
> + u64 hint;
> +
> + switch (cmd) {
> + case
Define a set of write life time hints:
and add an fcntl interface for querying these flags, and also for
setting them as well:
F_GET_RW_HINT Returns the read/write hint set.
F_SET_RW_HINT Pass one of the above write hints.
The user passes in a 64-bit pointer to get/set
17 matches
Mail list logo
