All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Zafman <dzafman@redhat.com>
To: "Sage Weil" <sage@newdream.net>, "Paweł Sadowski" <ceph@sadziu.pl>
Cc: ceph-users <ceph-users@ceph.com>, ceph-devel@vger.kernel.org
Subject: Re: [ceph-users] O_DIRECT on deep-scrub read
Date: Wed, 7 Oct 2015 12:51:57 -0700	[thread overview]
Message-ID: <561577DD.1050107@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1510070748580.8667@cobra.newdream.net>


There would be a benefit to doing fadvise POSIX_FADV_DONTNEED after 
deep-scrub reads for objects not recently accessed by clients.

I see the NewStore objectstore sometimes using the O_DIRECT  flag for 
writes.  This concerns me because the open(2) man pages says:

"Applications should avoid mixing O_DIRECT and normal I/O to the same 
file, and especially to overlapping byte regions in the same file.  Even 
when the filesystem correctly handles the coherency issues in this 
situation, overall I/O throughput is likely to be slower than using 
either mode alone."

David

On 10/7/15 7:50 AM, Sage Weil wrote:
> It's not, but it would not be ahrd to do this.  There are fadvise-style
> hints being passed down that could trigger O_DIRECT reads in this case.
> That may not be the best choice, though--it won't use data that happens
> to be in cache and it'll also throw it out..
>
> On Wed, 7 Oct 2015, Pawe? Sadowski wrote:
>
>> Hi,
>>
>> Can anyone tell if deep scrub is done using O_DIRECT flag or not? I'm
>> not able to verify that in source code.
>>
>> If not would it be possible to add such feature (maybe config option) to
>> help keeping Linux page cache in better shape?
>>
>> Thanks,
>>
>> -- 
>> PS
>>
>> _______________________________________________
>> ceph-users mailing list
>> ceph-users@lists.ceph.com
>> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


  parent reply	other threads:[~2015-10-07 19:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <56150598.1080604@sadziu.pl>
2015-10-07 14:50 ` [ceph-users] O_DIRECT on deep-scrub read Sage Weil
2015-10-07 15:18   ` Milosz Tanski
2015-10-07 19:51   ` David Zafman [this message]
2015-10-07 20:52     ` Sage Weil
     [not found]       ` <alpine.DEB.2.00.1510071349410.8667-vIokxiIdD2AQNTJnQDzGJqxOck334EZe@public.gmane.org>
2015-10-08  8:11         ` Paweł Sadowski
2015-10-09 16:54           ` [ceph-users] " Milosz Tanski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=561577DD.1050107@redhat.com \
    --to=dzafman@redhat.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=ceph-users@ceph.com \
    --cc=ceph@sadziu.pl \
    --cc=sage@newdream.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.