On Sat, Aug 19, 2017 at 4:27 PM, Csaba Henk wrote:
> Hi Niels,
>
> On Fri, Aug 11, 2017 at 2:33 PM, Niels de Vos wrote:
> > On Fri, Aug 11, 2017 at 05:50:47PM +0530, Ravishankar N wrote:
> [...]
> >> To me it looks like fadvise (mm/fadvise.c) affects only
Hi Niels,
On Fri, Aug 11, 2017 at 2:33 PM, Niels de Vos wrote:
> On Fri, Aug 11, 2017 at 05:50:47PM +0530, Ravishankar N wrote:
[...]
>> To me it looks like fadvise (mm/fadvise.c) affects only the linux page cache
>> behavior and is decoupled from the filesystem itself. What
On Fri, Aug 11, 2017 at 5:50 PM, Ravishankar N
wrote:
>
>
> On 08/11/2017 04:51 PM, Niels de Vos wrote:
>
>> On Fri, Aug 11, 2017 at 12:47:47AM -0400, Raghavendra Gowdappa wrote:
>>
>>> Hi all,
>>>
>>> In a conversation between me, Milind and Csaba, Milind pointed out
>>>
On Fri, Aug 11, 2017 at 05:50:47PM +0530, Ravishankar N wrote:
>
>
> On 08/11/2017 04:51 PM, Niels de Vos wrote:
> > On Fri, Aug 11, 2017 at 12:47:47AM -0400, Raghavendra Gowdappa wrote:
> > > Hi all,
> > >
> > > In a conversation between me, Milind and Csaba, Milind pointed out
> > >
On 08/11/2017 04:51 PM, Niels de Vos wrote:
On Fri, Aug 11, 2017 at 12:47:47AM -0400, Raghavendra Gowdappa wrote:
Hi all,
In a conversation between me, Milind and Csaba, Milind pointed out
fadvise(2) [1] and its potential benefits to Glusterfs' caching
translators like read-ahead etc. After
Hi,
Both swift[1] and gluster-swift[2] calls posix_fadvise64() with
POSIX_FADV_DONTNEED
right after calling fdatasync() or fsync(). This is only performed during
object PUT operation
(writing an object to disk) suggesting the kernel that the data written is
no longer needed
with the hopes that
Hi all,
In a conversation between me, Milind and Csaba, Milind pointed out fadvise(2)
[1] and its potential benefits to Glusterfs' caching translators like
read-ahead etc. After discussing about it, we agreed that our performance
translators can leverage the hints to provide better