ed by make check (so that a simple make check on a big
> endian box will catch errors). Ideally this'd be part of the
> test/encoding/readable.sh so that we run it over the entire corpus of old
> encodings..
>
>
> sage
> --
> To unsubscribe from this list: send the line "unsu
5IGJwwumHd5ozznpocy8Oj30N
>> +rNPJQ4dxcRao+bXUL/+DCQuY0wN/i7CqfMTW5PFmkdH4K9Lgce+bN6Q5Ora
>> q8JZvAxaZLCLZ10N+uiD5ghs+3X68hu4Da8SYQj0vjLs5gV4oATebF3JuYXW
>> GZ9qNfm2ygbeuT5Q0fhOKrvwJ9taKagMNrZLU10Wz5lHpGNitP3f17sVQznF
>> 7ZCkZ+2oS+P4Lerchc3xB2qBJUoPJGSuGAUTSl/uUeyMoZT1+2Lv
On Thu, Oct 22, 2015 at 11:16 PM, Howard Chu <h...@symas.com> wrote:
> Milosz Tanski adfin.com> writes:
>
>>
>> On Tue, Oct 20, 2015 at 4:00 PM, Sage Weil redhat.com> wrote:
>> > On Tue, 20 Oct 2015, John Spray wrote:
>> >> On Mon, Oc
e the
other one around (for investigation)
But makes me wonder that the broken dir scenario can probably be
replicated by hand using rados calls. There's a pretty generic ticket
there for don't die on dir errors, but I imagine the code can be
audited and steps to cause a synthetic error can be prod
asier route. Two, you can do it in the
DB layer (the LMDB transaction handling / locking) where you're
already started processing the following transactions using the
currently committing transaction (COW) as a starting point. This is
harder mostly because of the synchronization needed or involved.
I've
On Thu, Oct 22, 2015 at 8:48 AM, John Spray <jsp...@redhat.com> wrote:
> On Thu, Oct 22, 2015 at 1:43 PM, Milosz Tanski <mil...@adfin.com> wrote:
>> On Wed, Oct 21, 2015 at 5:33 PM, John Spray <jsp...@redhat.com> wrote:
>>> On Wed, Oct 21, 2015 at 10:33 PM,
On Wed, Oct 14, 2015 at 9:21 AM, John Spray <jsp...@redhat.com> wrote:
> On Mon, Oct 12, 2015 at 3:36 AM, Milosz Tanski <mil...@adfin.com> wrote:
>> On Sun, Oct 11, 2015 at 6:44 PM, Milosz Tanski <mil...@adfin.com> wrote:
>>> On Sun, Oct 11, 2015 at 6:01 PM, Mi
On Wed, Oct 14, 2015 at 12:46 AM, Gregory Farnum <gfar...@redhat.com> wrote:
> On Sun, Oct 11, 2015 at 7:36 PM, Milosz Tanski <mil...@adfin.com> wrote:
>> On Sun, Oct 11, 2015 at 6:44 PM, Milosz Tanski <mil...@adfin.com> wrote:
>>> On Sun, Oct 11, 2015 at 6:01
*, char const*, int, char
const*)+0x8b) [0x94cc1b]
2: /usr/bin/ceph-mds() [0x7c7df1]
3: (MDSIOContextBase::complete(int)+0x81) [0x7c83b1]
4: (Finisher::finisher_thread_entry()+0x1a0) [0x87f490]
5: (()+0x8182) [0x7fd4fd031182]
6: (clone()+0x6d) [0x7fd4fb7a047d]
NOTE: a copy of the executable,
On Sun, Oct 11, 2015 at 6:01 PM, Milosz Tanski <mil...@adfin.com> wrote:
> On Sun, Oct 11, 2015 at 5:33 PM, Milosz Tanski <mil...@adfin.com> wrote:
>> On Sun, Oct 11, 2015 at 5:24 PM, Milosz Tanski <mil...@adfin.com> wrote:
>>> On Sun, Oct 11, 2015 at 1:16 PM
On Sun, Oct 11, 2015 at 1:16 PM, Gregory Farnum <gfar...@redhat.com> wrote:
> On Sun, Oct 11, 2015 at 10:09 AM, Milosz Tanski <mil...@adfin.com> wrote:
>> About an hour ago my MDSs (primary and follower) started ping-pong
>> crashing with this message. I've spe
On Sun, Oct 11, 2015 at 5:24 PM, Milosz Tanski <mil...@adfin.com> wrote:
> On Sun, Oct 11, 2015 at 1:16 PM, Gregory Farnum <gfar...@redhat.com> wrote:
>> On Sun, Oct 11, 2015 at 10:09 AM, Milosz Tanski <mil...@adfin.com> wrote:
>>> About an hour ago my MDSs (pri
On Sun, Oct 11, 2015 at 5:33 PM, Milosz Tanski <mil...@adfin.com> wrote:
> On Sun, Oct 11, 2015 at 5:24 PM, Milosz Tanski <mil...@adfin.com> wrote:
>> On Sun, Oct 11, 2015 at 1:16 PM, Gregory Farnum <gfar...@redhat.com> wrote:
>>> On Sun, Oct 11, 2015 at 10:09
On Sun, Oct 11, 2015 at 6:44 PM, Milosz Tanski <mil...@adfin.com> wrote:
> On Sun, Oct 11, 2015 at 6:01 PM, Milosz Tanski <mil...@adfin.com> wrote:
>> On Sun, Oct 11, 2015 at 5:33 PM, Milosz Tanski <mil...@adfin.com> wrote:
>>> On Sun, Oct 11, 2015 at 5:24
;read only if in page cache"
> (preadv2/RWF_NONBLOCK) but can't find them in kernel source. Maybe
> Milosz Tanski can tell more about that. I think it could help a bit
> during deep scrub.
After a fair amount of bike shedding on the API (and removing
pwritev2) it looked like we (me an
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e:
or
electronically stored copies).
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel
/en/technologies/storage
tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309
- Original Message -
From: Milosz Tanski mil...@adfin.com
To: Haomai Wang haomaiw...@gmail.com
Cc: Yehuda Sadeh-Weinraub ysade...@redhat.com, Samuel Just
sj...@redhat.com, Sage Weil s...@newdream.net
) but the
notification mechanism will be both portable and transparent.
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord
/majordomo-info.html
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
system where we can
maximize available utilization, minimize disruptions, and not play
wack-a-mole with many conf knobs. I'm aware that this is much harder
to implement but thankfully there's a lot of literature,
implementation and practical experience out there to draw upon.
- Milosz
--
Milosz
or somewhere in the
OSD.
-- Tom
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info
in
the /etc/init/ceph-osd.conf upstart script
Regards,
Chaitanya
-Original Message-
From: ceph-devel-ow...@vger.kernel.org
[mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Mark Nelson
Sent: 28 April 2015 02:03
To: Milosz Tanski; Alexandre DERUMIER; ceph-devel; Somnath Roy
On 4/27/15 8:06 AM, Alexandre DERUMIER wrote:
Hi,
I'm hitting the tcmalloc even with patch apply.
It's mainly occur when I try to bench fio with a lot jobs (20 - 40 jobs)
Does It need to tuned something in osd environnement variable ?
I double check it with
#g++ -o gperftest
On 4/27/15 9:21 AM, Alexandre DERUMIER wrote:
Seem that starting osd with:
TCMALLOC_MAX_TOTAL_THREAD_CACHE_BYTES=128M /usr/bin/ceph-osd
fix it.
I don't known if it's the right way ?
Do you know what the default is if you don't specify it?
- Mail original -
De: aderumier
.
It looks like the mongodb people have run into a similar issue in a particular
(degenerate) case. Here's the ticket link for reference:
https://jira.mongodb.org/browse/SERVER-16551
- Mail original -
De: Mark Nelson mnel...@redhat.com
À: Milosz Tanski mil...@adfin.com
. If this is a problem it might be worth
to have an option to build tcmalloc (using a version know to be good)
into Ceph at build time.
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel
require some logic to merge
multiple unrelated Ceph OSD ops into a single LMDB transaction, but I
think it's doable.
- Theoretically you get to avoid a bunch of overhead of having a BTree
(database) on a BTree (filesystem).
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
://community.redhat.com
@scuttlemonkey || @ceph
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY
traffic,
repair traffic
I think it would be stair-forward to build the web app. In fact, I'll
volunteer myself for that task. Before we start that I would suggest
we try to get the model in something like Google Docs Sheets so we can
use it as a basis.
--
Milosz Tanski
CTO
16 East 34th Street, 15th
On Wed, Apr 1, 2015 at 9:49 AM, Sage Weil s...@newdream.net wrote:
On Wed, 1 Apr 2015, Milosz Tanski wrote:
On Wed, May 28, 2014 at 10:05 AM, Loic Dachary l...@dachary.org wrote:
On 28/05/2014 15:35, Koleos Fuskus wrote:
1. What will be erasure model unit? Is it a pool or a placement
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel
/FlameGraphs/cpuflamegraphs.html
- Mail original -
De: Mark Nelson mark.nel...@inktank.com
À: Milosz Tanski mil...@adfin.com, Mark Nelson mark.nel...@inktank.com
Cc: ceph-devel@vger.kernel.org
Envoyé: Mercredi 12 Novembre 2014 22:16:15
Objet: Re: Profiling with Perf
On 11/12/2014
this out... I hope it help you guys.
- Milosz
Mark
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
16 East 34th Street, 15th
...@lst.de
[mil...@adfin.com: comapt syscall changes for RWF_ODSYNC]
Signed-off-by: Milosz Tanski mil...@adfin.com
Reviewed-by: Jeff Moyer jmo...@redhat.com
Acked-by: Sage Weil s...@redhat.com
---
fs/ceph/file.c | 4 +++-
fs/fuse/file.c | 2 ++
fs/nfs/file.c | 10 ++
fs/ocfs2
this code.
Signed-off-by: Milosz Tanski mil...@adfin.com
Reviewed-by: Christoph Hellwig h...@lst.de
Reviewed-by: Jeff Moyer jmo...@redhat.com
Acked-by: Sage Weil s...@redhat.com
---
fs/ceph/file.c | 2 ++
fs/cifs/file.c | 6 ++
fs/nfs/file.c | 5 -
fs/ocfs2/file.c| 6
== WRITE (flags RWF_DSYNC))
return -EINVAL;
(no 'else' since the code will never be reached if the first test is
true).
--
Roger Willcocks ro...@filmlight.ltd.uk
This is what I changed it to (and will be sending that out for the
next version).
--
Milosz Tanski
CTO
16 East 34th
this code.
Signed-off-by: Milosz Tanski mil...@adfin.com
Reviewed-by: Christoph Hellwig h...@lst.de
Reviewed-by: Jeff Moyer jmo...@redhat.com
---
fs/ceph/file.c | 2 ++
fs/cifs/file.c | 6 ++
fs/nfs/file.c | 5 -
fs/ocfs2/file.c| 6 ++
fs/pipe.c | 3 ++-
fs
expensive.
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e
://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Mon, Sep 29, 2014 at 11:24 AM, Sage Weil sw...@redhat.com wrote:
On Mon, 29 Sep 2014, Milosz Tanski wrote:
A second more general Ceph question is somewhat off-topic. What about
C++11 use in the Ceph code base (like in this case)? It's not
explicitly prohibited by the coding style document
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Somnath
-Original Message-
From: Haomai Wang [mailto:haomaiw...@gmail.com]
Sent: Tuesday, September 23, 2014 7:07 PM
To: Sage Weil
Cc: Somnath Roy; Milosz Tanski; ceph-devel@vger.kernel.org
Subject: Re: Impact of page cache on OSD read performance for SSD
Good point, but do you have
in your possession (whether hard copies or
electronically stored copies).
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
16
than done and there are a lot of details to consider.
However it not different from maintaining an Operating System that includes
shared libraries and the path to do so properly is well known.
Thoughts ?
Cheers
--
Loïc Dachary, Artisan Logiciel Libre
--
Milosz Tanski
CTO
16 East 34th
primary affinity configuration?
Thanks,
Johnu
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo
-info.html
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
a default timeout value that works well and
avoid a tunable.
My self I thinking something like the 90th percentile time for page
write... whatever the value may be this should be a decent way of
auto-optimizing this timeout.
- M
On Wed, Jul 30, 2014 at 12:06 PM, Milosz Tanski mil...@adfin.com wrote:
I
21:48:34 -0400 Milosz Tanski mil...@adfin.com wrote:
I would vote on the lower end of the spectrum by default (closer to
100ms) since I imagine anybody deploying this in production
environment would likely be using SSD drives for the caching. And in
my tests on spinning disks there was little
at http://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info
.
- Milosz
On Tue, Jul 29, 2014 at 5:17 PM, NeilBrown ne...@suse.de wrote:
On Tue, 29 Jul 2014 17:12:34 +0100 David Howells dhowe...@redhat.com wrote:
Milosz Tanski mil...@adfin.com wrote:
That's the same thing exact fix I started testing on Saturday. I found that
there already
Default stack size shouldn't matter. At least it's not an issue on a kernel
with over-commit turned on (default). Most threads / apps never use that many
stack frames (in fact they use a fraction of that), thus the kernel doesn't
bother allocating the pages to it. My bet is on some other
[81083d69] kthread+0xc9/0xe0
[8101] ? ftrace_raw_event_xen_mmu_release_ptpage+0x70/0x90
[81083ca0] ? flush_kthread_worker+0xb0/0xb0
[8159eefc] ret_from_fork+0x7c/0xb0
[81083ca0] ? flush_kthread_worker+0xb0/0xb0
--
Milosz Tanski
CTO
16 East 34th Street
* the transaction handle. This also allows us to allocate
* the page (if needed) without using GFP_NOFS.
*/
retry_grab:
page = grab_cache_page_write_begin(mapping, index, flags);
if (!page)
On Sat, Jul 19, 2014 at 4:20 PM, Milosz Tanski mil...@adfin.com wrote:
Neil,
I
process ended, respawning
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
the
issue stopped. I ended up swapping the standby a couple times and it
looks like it's the standby code that's causing this leak.
TL;DR Standby is the one the leak... not sure what it is, but the
primary doesn't exhibit this behavior.
Best
- Milosz
On Mon, Apr 14, 2014 at 3:11 PM, Milosz Tanski
standby-replay
On Mon, Jun 23, 2014 at 3:27 PM, Gregory Farnum g...@inktank.com wrote:
Ah, excellent. What standby modes are you using?
-Greg
Software Engineer #42 @ http://inktank.com | http://ceph.com
On Mon, Jun 23, 2014 at 2:54 PM, Milosz Tanski mil...@adfin.com wrote:
I've spent more
::boot_start). Can you create a ticket?
-Greg
Software Engineer #42 @ http://inktank.com | http://ceph.com
On Mon, Jun 23, 2014 at 3:31 PM, Milosz Tanski mil...@adfin.com wrote:
standby-replay
On Mon, Jun 23, 2014 at 3:27 PM, Gregory Farnum g...@inktank.com wrote:
Ah, excellent. What standby
and ceph-devel. :)
-Greg
Software Engineer #42 @ http://inktank.com | http://ceph.com
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message
majordomo info at http://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
this from a Jenkins build, as
discussed on IRC.
On May 6, 2014 5:35:00 PM CEST, Milosz Tanski mil...@adfin.com wrote:
Indeed clangs warnings are much exhaustive. We've also had good
success with static analyzer based on clang
(http://clang-analyzer.llvm.org/). We've found a few logic issues
/majordomo-info.html
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks Greg; It looks like I was conflating a couple things.
On Wed, May 7, 2014 at 4:25 PM, Gregory Farnum g...@inktank.com wrote:
On Wed, May 7, 2014 at 1:13 PM, Milosz Tanski mil...@adfin.com wrote:
I was under the assumption that this was already in there (although
I'm using xfs) since
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil...@adfin.com
...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord
Sorry for not including the last on last email. It was an accident.
On Fri, Apr 11, 2014 at 6:23 PM, Gregory Farnum g...@inktank.com wrote:
On Fri, Apr 11, 2014 at 11:07 AM, Milosz Tanski mil...@adfin.com wrote:
On Fri, Apr 11, 2014 at 1:07 PM, Gregory Farnum g...@inktank.com wrote:
On Fri
, older Debian systems).
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
is also included to provide more context
when needed. Feel free to edit if you see a mistake.
Cheers
--
Loïc Dachary, Artisan Logiciel Libre
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send
Thanks Yan,
I'll test it early next week since we ended up reverting the client
for now since we're testing some other un-related internal project now
on that cluster.
- M
On Sat, Mar 29, 2014 at 2:01 AM, Yan, Zheng zheng.z@intel.com wrote:
On 03/29/2014 02:37 AM, Milosz Tanski wrote:
I
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
)
The corresponding thread is at:
https://bitbucket.org/jimplank/gf-complete/pull-request/4/defer-the-decision-to-use-a-given-sse/diff#comment-1479296
Cheers
--
Loïc Dachary, Artisan Logiciel Libre
--
Loïc Dachary, Artisan Logiciel Libre
--
Milosz Tanski
CTO
10
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord
I think it's good now, explicit (and detailed).
On Tue, Mar 18, 2014 at 4:12 PM, Sage Weil s...@inktank.com wrote:
On Tue, 18 Mar 2014, Sage Weil wrote:
On Tue, 18 Mar 2014, Milosz Tanski wrote:
Is this statement in the documentation still valid: Stale data is
expired from the cache pools
(...) designed by a deranged monkey text
in the open-2-manpage ;-)
-Dieter
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
10
not know how to use gmail.
On Fri, Jan 3, 2014 at 9:43 AM, Milosz Tanski mil...@adfin.com wrote:
I'm going to look the patches and the issue in full detail. In the
meantime do you guys have the oops back trace. I have some other
fscache patches that haven't made it upstream yet that might have been
for completion of object initialization
fs/ceph/cache.c |1 +
fs/ceph/cache.h | 10 ++
fs/ceph/file.c |3 +++
3 files changed, 14 insertions(+)
--
1.7.9.5
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil
of object initialization
fs/ceph/cache.c |1 +
fs/ceph/cache.h | 10 ++
fs/ceph/file.c |3 +++
3 files changed, 14 insertions(+)
--
1.7.9.5
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe
changed, 14 insertions(+)
--
1.7.9.5
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info
I hate to be that guy and keep bugging you guys. Can I get an
acknowledgment of the original patch? It fixed a very real issue for
fscache users that occurs semi-frequently under moderate concurrency.
- M
On Mon, Dec 16, 2013 at 12:20 PM, Milosz Tanski mil...@adfin.com wrote:
Hey guys it looks
it up. For us, we moved to jemalloc which does a fine job
returning the memory back to the OS.
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message
mds0 getattr #1346eed
15710 mds0 getattr #1346eed
15922 mds0 getattr #1346eed
On Wed, Nov 6, 2013 at 10:01 AM, Yan, Zheng uker...@gmail.com wrote:
On Wed, Nov 6, 2013 at 9:41 PM, Milosz Tanski mil...@adfin.com wrote:
Sage,
I think the incrementing version counter on the whole
, Zheng uker...@gmail.com wrote:
On Wed, Nov 20, 2013 at 12:05 AM, Milosz Tanski mil...@adfin.com wrote:
Yan and Sage,
I've ran into this issue again on my test cluster. The client hangs
all requests for a particular inode, I did a dump cache to see what's
going... but I don't understand to enough
in atomic context and the rest of the disable work can be
deferred till later.
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord
deletion(-)
--
1.7.9.5
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
...@redhat.com, linux-ker...@vger.kernel.org, Milosz
Tanski mil...@adfin.com
Fix the handling of an attempt to store a page that is now beyond EOF. This
may happen, for example, if the page got pushed for storage before the netfs
file got truncated on the server. In such a case, we should just
)
}
SetPageUptodate(page);
- if (err == 0)
+ if (err = 0)
ceph_readpage_to_fscache(inode, page);
out:
--
1.7.9.5
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil...@adfin.com
--
To unsubscribe from this list
On Wed, Nov 6, 2013 at 10:38 AM, Sage Weil s...@inktank.com wrote:
On Wed, 6 Nov 2013, Milosz Tanski wrote:
Sage,
I think the incrementing version counter on the whole is a neater
solution then using size and mtime. If nothing else it's more explicit
in the the read cache version. With what
array */
pool = NULL;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
10 East 53rd Street, 37th
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Milosz Tanski
CTO
10 East 53rd Street, 37th floor
New York, NY 10022
p: 646-253-9055
e: mil...@adfin.com
since it'll benefit all the fscache enabled
filesystems.
Thanks,
- Milosz
On Thu, Oct 3, 2013 at 12:43 PM, David Howells dhowe...@redhat.com wrote:
Milosz Tanski mil...@adfin.com wrote:
Stores : ops=10257 run=67477 pgs=57220 rxd=62216 olm=14
I think this line probably shows the problem. The olm
wt=0
Ops: pend=2600 run=148508 enq=371239 can=0 rej=0
Ops: dfr=1 rel=148508 gc=1
CacheOp: alo=0 luo=0 luc=0 gro=0
CacheOp: inv=0 upo=0 dro=0 pto=0 atc=0 syn=0
CacheOp: rap=0 ras=0 alp=0 als=0 wrp=0 ucp=0 dsp=0
On Mon, Sep 30, 2013 at 11:46 AM, Milosz Tanski mil...@adfin.com wrote:
Sorry I
...@gmail.com wrote:
On Mon, Sep 30, 2013 at 1:04 AM, Milosz Tanski mil...@adfin.com wrote:
David,
In my test cluster I started seeing an issue when the fscache get
stuck waiting on pending writes when doing page invalidate. The
problem happens because it looks like the page never leaves the
cookie
David,
In my test cluster I started seeing an issue when the fscache get
stuck waiting on pending writes when doing page invalidate. The
problem happens because it looks like the page never leaves the
cookie-store page tree.
I've been reading the different code paths in fscache/page.c to
This should not be a problem with Ceph as the MDS (the metadata
server) hands out cache capability bit for an inode. In this schema
there's no need to worry about the count of of local file pointers
open for write (or even across the cluster).
As an aside, the Ceph code checks if we can perform
Sage,
Can you submit to the upstream next in your next round of fixes (with
David's ack).
Thanks,
- Milosz
P.S: Thanks David.
On Tue, Sep 10, 2013 at 8:34 AM, David Howells dhowe...@redhat.com wrote:
Milosz Tanski mil...@adfin.com wrote:
__fscache_check_consistency() does not decrement
-kernelm=137849853203101w=2
Also, so far after making this change everything is peachy and theres
no other regressions.
P.S: This is a resend because I did no hit reply to ALL, sorry for the
spam David.
On Mon, Sep 9, 2013 at 6:18 AM, David Howells dhowe...@redhat.com wrote:
Milosz Tanski mil
1 - 100 of 173 matches
Mail list logo
