Hi,
I'm looking at ways to pass potentially messenger-specific options through the
Messenger factory.
The immediate parameter I need to provide is the number of Accelio portals to
set up (this should
vary by Messenger instance), but I expect others will be needed in future. I
don't think this
Hi,
- "Sage Weil" wrote:
> On Thu, 29 Jan 2015, Matt W. Benjamin wrote:
> > Hi,
> >
> > I'm looking at ways to pass potentially messenger-specific options
> through the Messenger factory.
> > The immediate parameter I need to provide is th
nger impl can introspect itself by
> "type", "policy", config and related infos?
>
> On Fri, Jan 30, 2015 at 12:44 AM, Matt W. Benjamin
> wrote:
> > Hi,
> >
> > - "Sage Weil" wrote:
> >
> >> On Thu, 29 Jan 2015, Matt W. Be
I was going to do a proplist arg type thing? I'll adapt it until hopefully
shared happiness breaks out...
Matt
- "Sage Weil" wrote:
> On Thu, 29 Jan 2015, Matt W. Benjamin wrote:
> > Hi,
> >
> > - "Sage Weil" wrote:
> >
> >
Hi,
We implemented an objectstore factory which does this, and could probably be
upstreamed.
Matt
- "Somnath Roy" wrote:
> Yes, we will take care of both, thanks..
>
> -Original Message-
> From: Sage Weil [mailto:s...@newdream.net]
> Sent: Wednesday, February 25, 2015 3:25 PM
>
This was just CMake build fixes.
Matt
--
Matt Benjamin
CohortFS, LLC.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://cohortfs.com
tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body
I'll send a submodule change. Apologies for the delay.
Matt
- "Somnath Roy" wrote:
> Hmm...I missed that part..I thought it would be a quick config fix
> :-(
> Yes, git submodule should be the approach.
>
> Thanks & Regards
> Somnath
>
> -Original Message-
> From: Sage Weil [mail
Hi,
Arent OFED dependencies already packaged? I assumed that only Accelio would
be a submodule.
Matt
- "Ken Dreyer" wrote:
> On 03/13/2015 05:44 PM, Sage Weil wrote:
> > On Fri, 13 Mar 2015, Somnath Roy wrote:
> >> Hi Sage,
> >> Why we are not building xio messenger by default like other
Hi,
Yes, agree. We do depend on librdmacm!
Matt
- "Ken Dreyer" wrote:
> On 03/16/2015 10:20 AM, Matt W. Benjamin wrote:
> > Hi,
> >
> > Arent OFED dependencies already packaged? I assumed that only
> Accelio would
> > be a submodule.
> &g
; Cleaning the repo and rebuilding solved the issue. Seems it was
> linking wrong libraries.
I think I've seen this.
>
> Thanks & Regards
> Somnath
>
>
> -Original Message-
> From: Matt W. Benjamin [mailto:m...@cohortfs.com]
> Sent: Monday, March 16, 2
rds
> Somnath
>
> -----Original Message-
> From: Matt W. Benjamin [mailto:m...@cohortfs.com]
> Sent: Monday, March 16, 2015 11:22 AM
> To: Somnath Roy
> Cc: ceph-devel@vger.kernel.org; Sage Weil; Ken Dreyer
> Subject: Re: xio messenger is not building by default
>
>
Hi Varada,
I pushed branch hammer-osfactory to https://github.com/linuxbox2/ceph.git
It can at least provide a starting point for discussion, if not a jumping off
point; I do think it's basically what Sage described.
I was able to update the CMake build system to build the tree, I haven't
attem
Seems good to me.
- "Sage Weil" wrote:
> On Sat, 11 Apr 2015, Varada Kari wrote:
> > Hi Matt/ Sage,
> >
> > Thanks for sharing the pull request. Will work on the items what
> sage
> > was mentioning in the comments along with the items in the tracker.
>
> I pushed a wip-plugin branch with
--Original Message-
> From: Sage Weil [mailto:s...@newdream.net]
> Sent: Tuesday, May 12, 2015 5:11 AM
> To: Varada Kari
> Cc: Loic Dachary; Matt W. Benjamin; ceph-devel
> Subject: RE: loadable objectstore
>
> Hi Varada,
>
> Any progress on this?
>
> Thanks!
&
Hi,
The issues Greg raises steered us away from stream compression, but I'm glad
you're experimenting with it.
We were/are interested in (block-oriented, generalized) dedup. For us, it was
clear that the different needs of users and changing capabilities of Ceph lead
to different strategies f
Hi Chaitanya,
Have you ruled out variants using fixed chunksize? (Arguments for/against
fingerprinting elided.)
Matt
- "Chaitanya Huilgol" wrote:
> Hi James et.al ,
>
> Here is an example for clarity,
> 1. Client Writes object object.abcd
> 2. Based on the crush rules, say OSD.a is th
I tend to support (++)
- "Piotr Dałek" wrote:
> > -Original Message-
> > From: Haomai Wang [mailto:haomaiw...@gmail.com]
> > Sent: Thursday, July 02, 2015 7:26 PM
> >
> > Yes, some fields only used for special ops. But union may increase
> the
> > complexity of stuct.
>
> Not by th
That makes sense.
Matt
- "James (Fei) Liu-SSI" wrote:
> Hi Casey,
> Got it. I was directed to the old code base. By the way, Since the
> testing case was used to exercise all of object stores. Strongly
> recommend to change the name from fio_ceph_filestore.cc to
> fio_ceph_objectstore.cc
Hi,
Couple of points.
1) a successor to 2Q is MQ (Li et al). We have an intrusive MQ LRU
implementation
with 2 levels currently, plus a pinned queue, that addresses stuff like
partitioning ("sharding"), scan resistance, and coordination w/lookup tables.
We might extend/re-use it.
2) I'm a b
Thanks for the explanations, Greg.
- "Gregory Farnum" wrote:
> On Tue, Jul 21, 2015 at 3:15 PM, Matt W. Benjamin
> wrote:
> > Hi,
> >
> > Couple of points.
> >
> > 1) a successor to 2Q is MQ (Li et al). We have an intrusive MQ LRU
> i
Hi,
- "Zhiqiang Wang" wrote:
> Hi Matt,
>
> > -Original Message-----
> > From: Matt W. Benjamin [mailto:m...@cohortfs.com]
> > Sent: Tuesday, July 21, 2015 10:16 PM
> > To: Wang, Zhiqiang
> > Cc: sj...@redhat.com; ceph-devel@vger.kernel.org
Hi,
- "Allen Samuels" wrote:
> I'm very concerned about designing around the assumption that objects
> are ~1MB in size. That's probably a good assumption for block and HDFS
> dominated systems, but likely a very poor assumption about many object
> and file dominated systems.
++
>
> If I
Hi Ilya,
The changes on this branch originated in our Ganesha NFS driver for
Ceph, so I'm not sure where the gap is, if any.
I'll send an update to the list when we've finish re-integrating against
the libcephfs-wip merge branch.
Matt
- "Ilya Storozhilov" wrote:
> Hi Ceph developers,
>
>
Hi,
1. in the cases where client caching is useful, AFS disk caching is still
common--though yes, giant memory caches became more common over time, and
2. a memory fs-cache backend is probably out there (I wonder if you can write
it in kernel mode), at worst, it looks like you can use cachefile
> is
> >= 2 it does. You'll see code to this effect in GNU find (which tries
> to
> use the link count to optimize its search when -type d).
>
> Thanks!
> sage
>
>
> >
> > Should we report this bugs on github?
> >
> >
> > Best regards!
> >
> > --
>
Hi All,
Just to confirm what Adam and I are doing on this end, ie, this is our plan to
rebase wip-libcephfs following wip-libcephfs-rebase.
* proceeding commit-wise on wip-libcephfs-rebase, mapping each change back to a
commit in wip-libcephfs
** striking out anything marked reject in rebase
**
Hi Sage,
- "Sage Weil" wrote:
>
> It might be simpler to just use the branch I already started and fix
> up
> the commit messages (git rebase -i master, 'e' for each commit, and
> git
> commit --amend on each to adjust the changelog).
Yes, doing exactly that.
>
> > Our work in progres
Hi Sage (et al),
We have rebased the former wip-libcephfs branch, on the model of the
rebased example branch, as planned, and also pulled it up to Ceph's
v65 tag/master, also as planned.
In addition to cross checking this, Adam has updated our Ganesha client
driver to use the ll v2 API, and this
o interpret this.
>
> It wasn't immediately obvious what the problem is except that it
> looked
> like a (ll_)refcounting issue. Also, the special-case of 'forget on
> root'
> looks suspicous; I'd like to pull in the patch from Ilya that takes a
> ref
>
Hi,
We tracked down the refcount issue found Sat., and have rebased/pushed
wip-libcephfs-rebased-v65
with the fix.
Thanks!
Matt
--
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI 48104
http://linuxbox.com
tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309
anges, which turned out to be an MDS bug
>
> turned by up the unit test.
>
> Is there a particular need for this to be in dumpling? I'm inclined
> to
> delay a release to avoid potentially destabliizing things this late in
> the
> game.
>
> Thanks!
> sage
>
;
> missing or if you've run into any issues since this branch was
> prepared.
> If everything looks okay I'd like to pull it in this week.
>
> Thanks!
> sage
>
>
> On Thu, 11 Jul 2013, Matt W. Benjamin wrote:
>
> > Hi Sage,
> >
Thanks for doing this. Also in the same interest of building Ceph faster, we've
been experimenting with a CMake translation of the current AM build. I have no
idea yet if it will be any help ;).
Matt
- "Noah Watkins" wrote:
> I'm so excited to have a refactored automake setup :)
>
> I wa
Hi David,
I'll have a loot.
Matt
- "David Zafman" wrote:
> I rebased wip-libcephfs and pushed as wip-libcephfs-emp-rb so that we
> can get this in to the Emperor release. Sage mentioned that he had hit
> a fuse problem in the wip-libcephfs branch, so apparently the problem
> is still prese
Hi All,
We're interested in this too. Isn't there a cluster wide/server ACL
representation component as well?
In the Ganesha and linux-nfs communities, there has been a combined discussion
with unification of ACLs for (eg)
SMB, and hence Rich ACLs.
Regards,
Matt
- "Zheng Yan" wrote:
>
Hi Michael,
Thanks for posting this.
We don't have specific workload information, but we did want to mention some of
the experimental Cephfs development we (Cohortfs) have been doing, in case it
might be of interest to others in the community.
One of the projects we've undertaken is to implement
Hi,
The Window NFS v4.1 client is what we work on, so this may be good for
code sharing. The license is lgplv2, like Ceph's.
Something important to be aware of is that the client uses rdbss, which
is a (partial) fsd abstraction that simplified implementation
quite a bit, kind of like a mini driv
work but all of those available source code everyone point
> at
> >> me will make our best solution. And in the end we will choose
> >> technologies knowing what we do and what concequencies they have.
> >>
> >> regards,
> >>
> >>
Yes. But you may wish to think about mingwXX porting rather than Cygwin,
if you prefer native results.
Matt
- "Noah Watkins" wrote:
> On Thu, Nov 7, 2013 at 5:15 PM, Sage Weil wrote:
>
> > curious if the discussion on windows portability is relevant here or
> if
> > it's better treated a
Or, MSVC, frankly.
- "Matt W. Benjamin" wrote:
> Yes. But you may wish to think about mingwXX porting rather than
> Cygwin,
> if you prefer native results.
>
> Matt
>
> - "Noah Watkins" wrote:
>
> > On Thu, Nov 7, 2013 at 5:
development is enormous :) So there are
> cygwin, mingw, and msvc. And mingw “more” native than cygwin, but
> doesn’t try to do posix, and msvc just the default/native windows
> development env?
>
> On Nov 7, 2013, at 5:34 PM, Matt W. Benjamin
> wrote:
>
> > Or, MSVC,
We are finding the cmake build system to be a big help, the compile-link-run
cylces seem much shorter.
Matt
- "Noah Watkins" wrote:
> On Nov 26, 2013, at 2:06 PM, Ali Maredia wrote:
>
> > Hi all,
> >
> > I'm a student working on a project to make ceph build faster and to
> help with effo
Hi,
I wondered about this. Were you able to measure an effect?
Thanks,
Matt
- "Zheng Yan" wrote:
>
> Besides, this feature should be disabled by default because it's not
> compatible with old clients and it imposes overhead on the mds. we
> need to use a config option or directory attri
Hi,
The CMake integration can help with this, as it can generate nmake files,
vs project files, etc.
Matt
- "Sage Weil" wrote:
> On Fri, 6 Dec 2013, James Harper wrote:
> > >
> > > > For win32 my current scheme is to just throw out all the
> configure and
> > > > automake stuff and have a
Hi Ceph devs,
For the last several weeks, we've been working with engineers at
Mellanox on a prototype Ceph messaging implementation that runs on
the Accelio RDMA messaging service (libxio).
Accelio is a rather new effort to build a high-performance, high-throughput
message passing framework atop
arer as I connect the XioMessenger to Ceph callers. As we've worked on the
prototype we've found a number of places where we could tweak the Accelio APIs
to good effect, and I think we'll find more places as continue work.
Matt
----- "Gregory Farnum" wrote:
>
HI Sage,
inline
- "Sage Weil" wrote:
> Hi Matt,
>
> Thanks for posting this! Some comments and questions below.
>
>
> I was originally thinking that xio was going to be more
> mellanox-specific,
> but it looks like it runs over multiple transports (even tcp!). (I'm
> sure
> I've been
M
> > To: Yaron Haviv
> > Cc: Atchley, Scott; Matt W. Benjamin; Sage Weil; ceph-devel; Eyal
> Salomon
> > Subject: Re: Ceph Messaging on Accelio (libxio) RDMA
> >
> > On Tue, Jan 7, 2014 at 11:52 AM, Yaron Haviv
> > wrote:
> > > [[YH]]
> > >
>
Hi Sage and Ceph devs,
Casey over here root-caused and we believe fixed the refcounting problem on our
wip-libcephfs branch, and
a rebase to firefly is in progress.
The fix is on wip-libcephfs-firefly-rb :
"""
fuse: fix for missing ll_ref on create
when the 'Inode **outp' argument was added to
here is a pull-request so I get this run through the test suite.
> This is
> the last week before the firefly freeze and it would be great to get
> this
> libcephfs API update into that release.
>
> sage
>
> On Fri, 7 Feb 2014, Matt W. Benjamin wrote:
>
> > H
This should be it:
https://github.com/linuxbox2/linuxbox-ceph/tree/wip-libcephfs-firefly-rb
Matt
- "Sage Weil" wrote:
> On Sat, 8 Feb 2014, Matt W. Benjamin wrote:
> > Hi,
> >
> > It looks to me like the rebase was already done--I thought Casey
> ne
oh, ok. I think they need an extra boost rpm?
- "Sage Weil" wrote:
> Hey Matt,
>
> This is in the libcephfs code I merged yesterday. Any ideas?
>
> Thanks!
> sage
>
>
> On Fri, 14 Feb 2014, Sandon Van Ness wrote:
>
> >
> > The last couple builds of master have been failing on the cen
but we haven't built on centos, to my knowledge...
----- "Matt W. Benjamin" wrote:
> oh, ok. I think they need an extra boost rpm?
>
> - "Sage Weil" wrote:
>
> > Hey Matt,
> >
> > This is in the libcephfs code I merged yesterday.
according to google, 1.41 ahould have it.
- "Sage Weil" wrote:
> On Fri, 14 Feb 2014, Matt W. Benjamin wrote:
> > but we haven't built on centos, to my knowledge...
>
> I think the question is really: is there an interval_set in boost 1.41
>
> that you
yarg, sorry
- "Josh Durgin" wrote:
> ICL was added in 1.46 according to http://www.boost.org/doc/libs/.
> This also fails on debian wheezy with only 1.42 available:
>
> http://tracker.ceph.com/issues/7422
>
> On 02/14/2014 04:26 PM, Matt W. Benjamin wrote:
&
g (start, end). I switched it to
> (start,
> offset) (since that's what our class does) but didn't verify the
> semantics
> were what was originally intended... can you take a look?
>
> https://github.com/ceph/ceph/pull/1253
>
> Thanks!
> sage
>
>
Hi,
I don't know, that's an interesting catch. I guess it's not really feasible to
do
anything accept ack this, for now.
Matt
- "Sage Weil" wrote:
> On Mon, 17 Feb 2014, Matt W. Benjamin wrote:
> > Hi Sage,
> >
> > I originally used this, a
Hi,
I think the offset,length change is probably not correct, since we need
to span the range actually being written.
Also we think that overlapping intervals are possible.
Matt
- "Sage Weil" wrote:
> On Mon, 17 Feb 2014, Matt W. Benjamin wrote:
> > Hi,
> >
&g
Hi,
Ok, sure, will follow up.
Matt
- "Sage Weil" wrote:
> On Mon, 17 Feb 2014, Matt W. Benjamin wrote:
> > Hi,
> >
> > I think the offset,length change is probably not correct, since we
> need
> > to span the range actually being written.
> >
Hi Greg,
- "Gregory Farnum" wrote:
> On Tue, Mar 18, 2014 at 1:05 PM, Yaron Haviv
> wrote:
> > Im happy to share test results we run in the lab with Matt's latest
> XioMessenger code which implements Ceph messaging over Accelio RDMA
> library
> > Results look pretty encouraging, demonstrati
Hi Mark,
- "Mark Nelson" wrote:
>
> Very nice! were you just writing to memory on the backend?
These are just passing 64K message payloads across the sender/receiver,
it's a message-passing workload comparison only.
>
> Mark
>
> >
> > Regards, Yaron
> >
> >
> >
> > --
> > To unsubscrib
Hi,
We've completed a trial merge of our current XioMessenger branches to Ceph
upstream master. The resulting branch is on our public Ceph development
repo, on banch xio-rados-firefly:
https://github.com/linuxbox2/linuxbox-ceph/commits/xio-rados-firefly
This branch isn't fully vetted. We haven
and take a preliminary look at this in the next day
> or two. What kind of feedback are you interested in right now?
> -Greg
> Software Engineer #42 @ http://inktank.com | http://ceph.com
>
> On Tue, Apr 22, 2014 at 12:44 PM, Matt W. Benjamin
> wrote:
> > Hi,
> >
>
Hi Greg,
- "Gregory Farnum" wrote:
>
> The re-org mostly looks fine.
> I notice you're adding a few more "friend" declarations though, and I
> don't think those should be necessary — Connection can label stuff as
> protected instead of private to help with that.
> PipeConnection should prob
Hi Greg,
I forgot to finish a couple of thoughts, filling them in...
- "Matt W. Benjamin" wrote:
> > > 2. about the completion mechanisms--with the addition of
> claim_data,
> > this
> > > is provisionally complete
> >
> > Can you talk abo
Hi,
The XioMessenger work provides native support for Infiniband, if I understand
you correctly.
Early testing is now possible, on a codebase pulled up to Firefly. See
discussion
from earlier this week.
Regards,
Matt
- "Gandalf Corvotempesta" wrote:
> 2014-04-30 14:18 GMT+02:00 Sage We
Hi,
Sure, that's planned for integration in Giant (see Blueprints).
Matt
- "Gandalf Corvotempesta" wrote:
> 2014-05-01 0:11 GMT+02:00 Mark Nelson inktank.com>:
> > Usable is such a vague word. I imagine it's testable after a
> fashion. :D
>
> Ok but I prefere an "official" support with I
Hi,
I should have been careful. Our efforts are aimed at Giant. We're
serious about meeting delivery targets. There's lots of shakedown, and
of course further integration work, still to go.
Regards,
Matt
- "Gandalf Corvotempesta" wrote:
> 2014-05-01 0:20 GMT
Hi,
Is there a known time at the Summit when this discussion might be taking place?
I have limited time window during which I could be present, but would make an
effort to do so. I'm mostly interested in listening in, but have some useful
context (OpenAFS foundation, not a board member).
Regard
Hi Ceph Devs,
I've pushed two Ceph+Accelio branches, xio-firefly and xio-firefly-cmake to our
public ceph repository https://github.com/linuxbox2/linuxbox-ceph.git .
These branches are pulled up to the HEAD of ceph/firefly, and also have
improvements
to XioMessenger which allow:
1. operation of
e the
intra-cluster messaging paths work, and a client workload may work--more fixes
likely forthcoming.
I have a plan to get at least the starter policy interfaces like mark_down and
mark_down_all shorty.
Matt
- "Gregory Farnum" wrote:
> On Tue, May 13, 2014 at 2:08 PM, Matt
Hi Ceph devs,
I pushed a small set of changes against Firefly to permit building with
-std=std++11 (actually I'm using -std=gnu++11 atm, due to a problem in a
fio header).
If folks are interested:
To https://github.com/linuxbox2/linuxbox-ceph.git
* [new branch] firefly-std11 -> firefly-std
Hi Sage,
Sure, I'll join the core standup. I think you have the right ideas, I'll give
it some more thought as well, before tomorrow's meeting.
Thanks,
Matt
- "Sage Weil" wrote:
> Hey Matt,
>
> Can you join us for the core standup tomorrow, or shortly after, to
> sycn
> up on the messe
+1
- "Sage Weil" wrote:
>
> Anyway, at the end of the day, small writes or overwrites would still
> be
> journaled, but large writes or large new objects would not, which
> would (I
> think) be a pretty big improvement.
Yes.
Overall, I think the design will
> be
> much simpler to rea
Hi,
We noticed that OSDs use their client_messenger, rather than their potentially
dedicated cluster_messenger, to drive MonClient. Then we found that the Mon's
setup
of the OSDMap depends on this.
Can someone comment? We assume this is well known, but what is the background?
Thanks,
Matt
-
This approach/family of approaches is certainly the one taken by all classical
Kerberized file sharing systems, including AFS, DCE, and NFSv4.
There's a lot of new work just coming to fruition now in both the AFS and NFSv4
communities (rxgk and RPCSEC_GSS, respectively) that are specifically des
Sorry, s/RPCSEC_GSS/RPCSEC_GSSv3/.
- "Matt W. Benjamin" wrote:
> This approach/family of approaches is certainly the one taken by all
> classical Kerberized file sharing systems, including AFS, DCE, and
> NFSv4.
>
> There's a lot of new work just coming t
Hi Chris,
- "Christopher R. Hertel" wrote:
> Matt:
>
> Thanks for the pointers. I'm currently knee-deep in traditional
> Kerberos authentication code and trying to crack the FreeIPA PAM
> API.
>
> I'm a community-oriented developer. Any deeper dive you can
> provide would be encouraging.
Hi Sage,
Great idea, we'd certainly be interested in attending.
We have a variety of potentially relevant work, some (but not all) at least
tangentially related to RDMA. Our attention is necessarily split between
upstream and internal branches (that currently don't have CRUSH, PGs, etc), but
Hi,
1. Agree (our item in the pad). We have prototyped something that works for
us, but some work might be needed to make it useful upstream.
2. Accelio/XioMessenger does well on the front side. It will be interesting to
compare notes.
Matt
- "Haomai Wang" wrote:
> Thanks for sage!
Sorry we missed this one, we had a combination of meeting conflict and a
technical problem,
we'll join next week.
Matt
- "Sage Weil" wrote:
> Thanks, everyone, for joining! I took some notes during the session
> in
> the etherpad:
>
> http://pad.ceph.com/p/performance_weekly
>
-
Having trouble joining. No feedback on why from the BlueJeans plugin.
Matt
- "Mark Nelson" wrote:
> Hi All,
>
> Just a reminder that the weekly performance meeting is on Wednesdays
> at
> 8AM PST!
>
> Etherpad URL:
> http://pad.ceph.com/p/performance_weekly
>
> To join the Meeting:
> h
company.
>
> Mark
>
> On 10/15/2014 10:50 AM, Matt W. Benjamin wrote:
> > Having trouble joining. No feedback on why from the BlueJeans
> plugin.
> >
> > Matt
> >
> > - "Mark Nelson" wrote:
> >
> >> Hi All,
> >>
Hi Folks,
Per yesterday's Ceph performance call, we've pushed 2 wip branches for review
and feedback to https://github.com/linuxbox2/linuxbox-ceph.git .
1. xio-v084-inline reorganizes ceph::buffer as a namespace, and (nearly) all of
buffer::hash, buffer::ptr and buffer::list as inline
2. xio-v0
; accident... :-)
>
> https://github.com/ceph/ceph/pull/2595
>
> and
>
> https://github.com/dachary/ceph/commit/734e555c640a3b5e9bbf0329bd524cffaca61c4f
>
> in particular. It does not do anything performance wise but it's going
> to be merged in the not-to-dista
Hi,
- "Haomai Wang" wrote:
> [cc to ceph-devel]
>
> >> At first FileStore will directly accept inputs without bufferlist
> >> encode/decodes. Now I try to send MOSDOP's payload directly to
> >> replicate PG and avoid overall ObjectStore::Transaction which is
We did something similar to thi
Hi,
Is the goal then NOT to provide per-user authn (etc) as AFS or DCE would do,
when a user accesses files using the kernel client (and provide for that, in
general)? I would have thought that was a lot of the point.
It seems like that is the well trodden path, for AFS, DFS, NFSv4, it's
basi
I meant to say, per-user protection.
Matt
- "Matt W. Benjamin" wrote:
> Hi,
>
> Is the goal then NOT to provide per-user authn (etc) as AFS or DCE
> would do, when a user accesses files using the kernel client (and
> provide for that, in general)? I would have
Hi Sage,
We're starting a round of work on improving encode/decode workload profiling,
which we'll
share as soon as we have something informative.
Matt
- "Sage Weil" wrote:
> We talked a bit about improving the performance encode/decode
> yesterday at CDS:
>
> http://pad.ceph.com/
We have a simple perf test results and a overview design ppt. Hope we
> can have a talk at 8:00(CST).
>
> On Thu, Oct 30, 2014 at 1:23 AM, Matt W. Benjamin
> wrote:
> > Hi Sage,
> >
> > We're starting a round of work on improving encode/decode workload
> profi
Hi,
Just wanted to say, Ali here has been experimenting with these as well, and,
although
I don't have any specifics yet, we'll contribute anything we come up with that
looks
helpful.
Thanks all very much for the work,
Matt
- "Mark Nelson" wrote:
> On 10/30/2014 01:49 PM, Andrew Shewmak
Hi,
As Vu mentioned in the performance call, we've created a pull request including
just the ceph:buffer::* changes, to get review and show non-regression.
https://github.com/linuxbox2/linuxbox-ceph/pull/1
Thanks,
Matt
--
Matt Benjamin
CohortFS, LLC.
315 West Huron Street, Suite 140A
Ann Arbo
Hi devs,
We've created a new branch wip-claim-2, and new pull request
https://github.com/linuxbox2/linuxbox-ceph/pull/3
based on review feedback.
The big change is to replace "volatile" with "sharable", and replace
"strong_claim()" with "clone_nonsharable()."
This may not be perfect, feedback a
Pushed wip-claim-3, which makes the changes you requested in IRC, plus adds a
unittest block.
Matt
- "Sage Weil" wrote:
> On Mon, 8 Dec 2014, Matt W. Benjamin wrote:
> > Hi devs,
> >
> > We've created a new branch wip-claim-2, and new pull request
>
Hi Ceph Devs,
We've put together a "pre" pull request for review of the XioMessenger
integration against Hammer.
https://github.com/ceph/ceph/pull/3224
This is a re-based version of our weekly mix-down, the parent branch was
looking quite good.
Thanks!
Matt
--
Matt Benjamin
CohortFS, LLC.
Hi Ceph folks,
Summarizing from Ceph IRC discussion by request, I'm one of the developers of a
pNFS (parallel nfs) implementation that is built atop the Ceph system.
I'm working on code that wants to use the Ceph caps system to control and
sequence i/o operations and file metadata, for example,
s with metadata correctly but it's not what
we want.To compose the bypass data path with stability, the DS gains the
obligation to update inode state itself. Looking at whether the DS could do
this using Ceph protocol, is what led me to start the conversation.
Thanks,
Matt
----- "Matt
hence client and DS may both safely rely on this. Plus, of course, other Ceph
clients see a sane view
of the affected objects at any point in this process.
Matt
>
> Maybe just describing what exactly is contained in the layout would
> help
> me understand the context.
>
> Tha
Hi Sage,
- "Sage Weil" wrote:
>
> Your prevoius question made it sound like the DS was interacting with
>
> libcephfs and dealing with (some) MDS capabilities. Is that right?
>
> I wonder if a much simpler approach would be to make a different fh
> format
> or type, and just cram the in
Hi,
Along the same lines, (p)NFS access from Windows clients should already be
possible, for some definition of possible. We'll make it actually possible
over the next few months.
Matt
- "Sage Weil" wrote:
> On Wed, 9 Jan 2013, Florian Haas wrote:
> > On Tue, Jan 8, 2013 at 3:00 PM, D
1 - 100 of 111 matches
Mail list logo
