Thanks for explaining it.
I read the source code and confirmed that read operations incur more
drop_cache calls than write operations. However, I am not sure
whether the additional calls result in significant overhead. Need some
tests to verify.
Gerald
On Tue, Dec 13, 2011 at 11:32 PM, Michael
Thanks. Now, I understand the access pattern Swift is designed for.
Do you know some real applications (or scenarios, use cases) that
benefit from that design (except static image files)?
Gerald
On Wed, Dec 14, 2011 at 1:17 AM, Michael Barton
mike-launch...@weirdlooking.com wrote:
On Tue, Dec
On Wed, Dec 14, 2011 at 5:38 PM, Ewan Mellor ewan.mel...@eu.citrix.com wrote:
Or static disk image files!
Only if you've got enough RAM on the storage worker node to cache the entire
disk image. Otherwise it's just going to get evicted straight away.
The case where you've got so few,
are faster than reads in Swift
On Wed, Dec 14, 2011 at 5:38 PM, Ewan Mellor ewan.mel...@eu.citrix.com wrote:
Or static disk image files!
Only if you've got enough RAM on the storage worker node to cache the entire
disk image. Otherwise it's just going to get evicted straight away.
The case where
On Thu, Dec 15, 2011 at 2:55 PM, Ewan Mellor ewan.mel...@eu.citrix.com wrote:
Your simulation is of the one case that I said would work: when you have
enough RAM to cache the entire image.
When you _don't_ have enough RAM, then the images will just immediately be
evicted, and the
On Wed, Dec 14, 2011 at 1:17 AM, Michael Barton
mike-launch...@weirdlooking.com wrote:
On Tue, Dec 13, 2011 at 9:21 PM, Huang Zhiteng winsto...@gmail.com wrote:
Can anyone explain why Swift doesn't want to utilize page cache _at all_?
It's an artifact of the use case swift was built for -
: Re: [Openstack] Writes are faster than reads in Swift
On Wed, Dec 14, 2011 at 1:17 AM, Michael Barton
mike-launch...@weirdlooking.com wrote:
On Tue, Dec 13, 2011 at 9:21 PM, Huang Zhiteng winsto...@gmail.com
wrote:
Can anyone explain why Swift doesn't want to utilize page cache _at
all_
I can't explain it off the top of my head.
I don't have a swift installation to play with at the moment, but it's
conceivable that posix_fadvise is slower than we expect (drop_cache is
called more frequently during reads than writes, iirc). That could be
tested by making drop_cache a no-op in
Can anyone explain why Swift doesn't want to utilize page cache _at all_?
On Wed, Dec 14, 2011 at 12:32 PM, Michael Barton
mike-launch...@weirdlooking.com wrote:
I can't explain it off the top of my head.
I don't have a swift installation to play with at the moment, but it's
conceivable
On Tue, Dec 13, 2011 at 9:21 PM, Huang Zhiteng winsto...@gmail.com wrote:
Can anyone explain why Swift doesn't want to utilize page cache _at all_?
It's an artifact of the use case swift was built for - heavy on
writes, and repeat reads (where a cache would help) are very rare.
Having that
10 matches
Mail list logo