Milosz Tanski wrote:
> It looks like both the cifs and NFS code do not bother with any
> locking around cifs_fscache_set_inode_cookie. Is there no concern over
> multiple open() calls racing to create the cookie in those
> filesystems?
Yeah... That's probably wrong. AFS obviates the need for s
On Tue, 2013-07-09 at 11:33 +0100, David Howells wrote:
> Milosz Tanski wrote:
>
> > It looks like both the cifs and NFS code do not bother with any
> > locking around cifs_fscache_set_inode_cookie. Is there no concern over
> > multiple open() calls racing to create the cookie in those
> > filesy
On Tue, Jul 9, 2013 at 6:33 AM, David Howells wrote:
> Milosz Tanski wrote:
>
>> It looks like both the cifs and NFS code do not bother with any
>> locking around cifs_fscache_set_inode_cookie. Is there no concern over
>> multiple open() calls racing to create the cookie in those
>> filesystems?
David,
On a somewhat related node. The header definition of
fscache_maybe_release_page doesn't seam quite correct. The comment
states it should return true if the page can be freed ... yet when
there's not a cookie or PG_fscache is not set it returns false. This
doesn't seam right, in fact the NFS
David,
I have another one for you... I though maybe I caused this somehow so
I spent like 8 hours tracking. But now I'm not so sure. I got this
error when running this "stress test"
root@pbnode-58019a39:/mnt/cluster/petabucket/prod# find -type f |
xargs -P 16 cat | pv > /dev/null
^C83GB 0:00:52
Fixes bug 5528
Since it returns all xattrs, it does not take an xattr_name. Also,
add unit tests for the Object xattrs methods.
Signed-off-by: Johannes Erdfelt
---
src/pybind/rados.py | 4 ++--
src/test/pybind/test_rados.py | 12
2 files changed, 14 insertions(+), 2 dele
I'm getting the following failure when running a vstart instance with
1 of each daemon.
--
0> 2013-07-09 08:30:43.213345 7fdc289e97c0 -1 mon/OSDMonitor.cc: In
function 'virtual void OSDMonitor::update_from_paxos(bool*)' thread
7fdc289e97c0 time 2013-07-09 08:30:43.207686
mon/OSDMonitor.cc: 129: F
It turns out that I did this to myself with the launder_page callback
that implemented. Originally I would be able to solve the occasional
page left over with PG_fscache mark.
- Milosz
On Tue, Jul 9, 2013 at 10:07 AM, Milosz Tanski wrote:
> David,
>
> I have another one for you... I though maybe
Our last development release before dumpling is here! The main
improvements here are with monitor performance and OSD pg log rewrites to
speed up peeering.
In other news, the dumpling feature freeze is upon us. The next month
we will be focusing entirely on stabilization and testing. There w
Hi Linus,
Please pull the following Ceph updates from
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus
There is some follow-on RBD cleanup after the last window's code drop, a
series from Yan fixing multi-mds behavior in cephfs, and then a sprinkling
of bug fixes
On 07/09/2013 04:37 PM, Noah Watkins wrote:
I'm getting the following failure when running a vstart instance with
1 of each daemon.
I can confirm this happens, as it just happened to me as well.
My guess is that this is something Sage may have fixed last night, but
will have to check.
-Jo
It appears to be resolved in master now.
On Tue, Jul 9, 2013 at 12:43 PM, Joao Eduardo Luis
wrote:
> On 07/09/2013 04:37 PM, Noah Watkins wrote:
>>
>> I'm getting the following failure when running a vstart instance with
>> 1 of each daemon.
>
>
> I can confirm this happens, as it just happened t
On 07/09/2013 08:45 PM, Noah Watkins wrote:
It appears to be resolved in master now.
Yep!
-Joao
On Tue, Jul 9, 2013 at 12:43 PM, Joao Eduardo Luis
wrote:
On 07/09/2013 04:37 PM, Noah Watkins wrote:
I'm getting the following failure when running a vstart instance with
1 of each daemon.
Hi,
I am trying to collect memory of the OSD daemon with the following
./vstart.sh -n -x -l --valgrind_osd 'massif'
However, when I print massif.out file there is nothing
cat massif.out.15391
desc: (none)
cmd: ./ceph-osd -i 0 -c ceph.conf -f
time_unit: i
#---
snapshot=0
#---
ti
Hi,
I ran into this problem a while back and it was because I was trying to
use a version of valgrind that didn't support tcmalloc (which Ceph was
compiled to use). Try upgrading valgrind to 3.8.0 or newer. You'll
also need to pass something like:
--soname-synonyms=somalloc=*tcmalloc*
Mar
Hi,
We did a simple throughput test on Ceph with 2 OSD nodes configured
with one replica policy. For each OSD node, the throughput measured by
'dd' run locally is 117MB/s. Therefore, in theory, the two OSDs could
provide 200+MB/s throughput. However, using 'iozone' from clients we
only get a
16 matches
Mail list logo