Hi Andreas,
That sounds reasonable. Would you be so kind as to send a patch with your
changes ? I'll rework it into something that fits the test infrastructure of
Ceph.
Cheers
On 22/09/2013 09:26, Andreas Joachim Peters wrote:
Hi Loic,
I run a benchmark with the changed code tomorrow ... I
On 09/22/2013 03:12 AM, Quenten Grasso wrote:
Hi All,
I’m finding my write performance is less than I would have expected.
After spending some considerable amount of time testing several
different configurations I can never seems to break over ~360mb/s
write even when using tmpfs for
On Sun, Sep 22, 2013 at 07:40:24AM -0500, Mark Nelson wrote:
On 09/22/2013 03:12 AM, Quenten Grasso wrote:
Hi All,
I’m finding my write performance is less than I would have
expected. After spending some considerable amount of time testing
several different configurations I can never
Hello,
Since it was a long time from enabling cephx by default and we may
think that everyone using it, is seems worthy to introduce bits of
code hiding the key from cmdline. First applicable place for such
improvement is most-likely OpenStack envs with their sparse security
and usage of admin
Hi Loic,
I was applying the changes and the
situation improves, however there is still one important thing which
actually dominated all the measurements which were needing larger packet
sizes (everything besides Raid6):
pad_in_length(unsigned in_length)
The
As Yan,Zheng said, commit 0913444208db intruoduce a bug:getattr need to
read lock inode's filelock. But the lock can be in unstable state.
the getattr request waits for lock's state to become stable, the lock
waits for client to release Fr cap.
Commit 6a026589ba333185c466c90 resolved the same bug
Reviewed-by: Sage Weil s...@inktank.com
On Sun, 22 Sep 2013, Yan, Zheng wrote:
From: Yan, Zheng zheng.z@intel.com
call __queue_cap_release() in __ceph_remove_cap(), this avoids
acquiring s_cap_lock twice.
Signed-off-by: Yan, Zheng zheng.z@intel.com
---
fs/ceph/caps.c |
