> -Original Message-
> From: ceph-devel-ow...@vger.kernel.org
> [mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Dennis Chen
> Sent: Tuesday, January 27, 2015 3:07 PM
> To: ceph-devel@vger.kernel.org; Dennis Chen
> Subject: [Questions]Can client know which OSDs are storing the data?
>
Hello Guys,
My question is very rude and direct, a little bit stupid maybe ;-)
Question a: a client write a file to the cluster (supposing replica =
3), so the data will be stored in 3 OSDs within the cluster, can I get
the information of which OSDs storing the file data in client side?
Question
Not sure if it is correct, but below is my understanding. Correct me if I'm
wrong.
Yes, in the current code, a hash lookup on each IO is used to check dup op. But
when adding extra_reqids as a log entry in the pg_log, 2 hash lookups may be
not sufficient. The extra_reqids is organized by object
On 01/20/2015 06:41 AM, Ilya Dryomov wrote:
> If the clone is resized down to 0, it becomes standalone. If such
> resize is carried over while an image is mapped we would detect this
> and call rbd_dev_parent_put() which means "let go of all parent state,
> including the spec(s) of parent images(s
On 01/20/2015 06:41 AM, Ilya Dryomov wrote:
> This effectively reverts the last hunk of 392a9dad7e77 ("rbd: detect
> when clone image is flattened").
>
> The problem with parent_overlap != 0 condition is that it's possible
> and completely valid to have an image with parent_overlap == 0 whose
> pa
On 01/20/2015 06:41 AM, Ilya Dryomov wrote:
> The comment for rbd_dev_parent_get() said
>
> * We must get the reference before checking for the overlap to
> * coordinate properly with zeroing the parent overlap in
> * rbd_dev_v2_parent_info() when an image gets flattened. We
> * d
On Mon, 26 Jan 2015, Samuel Just wrote:
> The pg_log_t variant does seem to be cleaner.
I forgot, here is the danger: on promote and flush (copy-from) we do an
O(n) scan of the pg log to assemble the reqids for that object. Current
default is 1000 entries in the log.
We could do better than th
Loic,
Here is the run from sepia
http://pulpito.front.sepia.ceph.com/ubuntu-2015-01-26_09:26:27-upgrade:dumpling-dumpling-distro-basic-vps/
Two failures seems like env noise.
Thx
YuriW
On Mon, Jan 26, 2015 at 9:49 AM, Loic Dachary wrote:
> Thanks for letting me know about the upgrade tests res
Hi Stephen,
Does this explain the results you were seeing earlier with the memstore
testing?
Mark
On 01/26/2015 12:00 PM, Blinick, Stephen L wrote:
Good to know, I was wondering why the spec file defaulted to lib-nss.. the
dpkg-build for debian packages just uses whatever configuration you
Good to know, I was wondering why the spec file defaulted to lib-nss.. the
dpkg-build for debian packages just uses whatever configuration you had built,
and I believe that will use libcryptopp if the dependency is installed on the
build machine (last I looked).
I forgot to mention the numbers
Thanks for letting me know about the upgrade tests results, it's encouraging
:-) I'll let you know when the tests make progress.
On 26/01/2015 18:00, Yuri Weinstein wrote:
> Loic,
>
> Thanks for the update.
> I ran upgrade/dumpling last week (and all 42 jobs passed in octo and
> sepia) to establ
The pg_log_t variant does seem to be cleaner.
-Sam
On Mon, Jan 26, 2015 at 9:21 AM, Sage Weil wrote:
> On Mon, 26 Jan 2015, Wang, Zhiqiang wrote:
>> The downside of this approach is that we may need to search the pg_log
>> for a specific object in every write io?
>
> Not quite. IndexedLog mainta
On Mon, 26 Jan 2015, Blinick, Stephen L wrote:
> I noticed that the spec file for building RPM's defaults to building with
> libnss, instead of libcrypto++. Since the measurements I'd done so far were
> from those RPM's I rebuilt with libcrypto++.. so FWIW here is the difference
> between those
On Mon, 26 Jan 2015, Wang, Zhiqiang wrote:
> The downside of this approach is that we may need to search the pg_log
> for a specific object in every write io?
Not quite. IndexedLog maintains a hash_map of all of the request ids in
the log, so it's just a hash lookup on each IO. (Well, now 2 h
Loic,
Thanks for the update.
I ran upgrade/dumpling last week (and all 42 jobs passed in octo and
sepia) to establish a base line. And today running another one,
assuming it will pick up the already merged pull requests.
Let me know when you ready for next steps.
Thx
YuriW
On Mon, Jan 26, 2015
-- All Branches --
Adam Crume
2014-12-01 20:45:58 -0800 wip-doc-rbd-replay
Alfredo Deza
2014-07-08 13:58:35 -0400 wip-8679
2014-09-04 13:58:14 -0400 wip-8366
2014-10-13 11:10:10 -0400 wip-9730
Andreas-Joachim Peters
2014-10-15 15:09:24 +0200 a
Hi Yuri,
Here is a short update on the progress of the upcoming dumpling v0.67.12.
It is tracked with http://tracker.ceph.com/issues/10560. In the inventory part,
there is a list of all pull requests that are already merged in the dumpling
branch. There only is one pull request waiting to be me
ARMv8 defines a set of optional CRC32/CRC32C instructions.
This patch defines an optimized function that uses these
instructions when available rather than table-based lookup.
Optimized function based on a Hadoop patch by Ed Nevill.
Autotools updated to check for compiler support.
Optimized functi
Hi,
Thanks for the snippet, I'll add it to the non regression from the pull request
you sent :-)
Cheers
On 26/01/2015 06:43, Miyamae, Takeshi wrote:
> Hi Loic,
>
>> Note that you also need to update
>
> We have prepared mSHEC's parameter sets which we think will be commonly used.
> Because I'
Hi Loic,
I have noticed that your repository ceph-erasure-code-corpus is forked for us,
so I created a new pull request.
Update non-regression.sh #1
https://github.com/t-miyamae/ceph-erasure-code-corpus/pull/1
Best regards,
Takeshi Miyamae
-Original Message-
From: Miyamae, Takeshi/宮前 剛
20 matches
Mail list logo
