Re: cmake

nd cmake to build a relelase > > > > I'm probably missing something? > > > > Should we set a target of doing the 10.0.2 or .3 with cmake? > > > > sage > > -- > > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > &g

Re: Improving Data-At-Rest encryption in Ceph

. > > > Regards, > Lars > > -- > Architect Storage/HA > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB > 21284 (AG Nürnberg) > "Experience is the name everyone gives to their mistakes." -- Oscar Wilde > -- -- Matt Benj

Re: queue_transaction interface + unique_ptr + performance

y, December 3, 2015 6:50:26 AM > Subject: RE: queue_transaction interface + unique_ptr + performance > > 1- I agree we should avoid shared_ptr whenever possible. > > > sage -- -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://

Re: cmake

/ceph/ceph-tip/CMakeFiles/CMakeOutput.log". > [zaitcev@lembas ceph-tip]$ rpm -qa | grep -i cmake > extra-cmake-modules-5.16.0-1.fc23.noarch > cmake-3.3.2-1.fc23.x86_64 > [zaitcev@lembas ceph-tip]$ > > Is this expected? Is my cmake incantation wrong? > > Thanks, > -- Pete &g

Re: cmake

sorry, "cmake .." for Ceph's setup. Matt - Original Message - > From: "Matt Benjamin" <mbenja...@redhat.com> > To: "Pete Zaitcev" <zait...@redhat.com> > Cc: ceph-devel@vger.kernel.org > Sent: Thursday, December 3, 2015 5:30:28 PM >

Re: cmake

Do you know by any chance where it gets that include? Also, what's > your cmake --version? > > Greetings, > -- Pete > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majord...@vger.kernel.org > More majordomo i

Re: ack vs commit

h, and doesn't get changed much anyway. If we drop this now > and decide to bring back any similar semantic in the future I think > that'll be a lot harder than simply carrying it, both in terms of > banging it back into the code, and especially in terms of getting it > deployed to all t

Re: nfsv41 over AF_VSOCK (nfs-ganesha)

For hacking around, put "Graceless = true;" in the NFSV4 block. Matt -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-707-0660 fax. 734-769-8938 cel. 734-216-5309 - Origin

Re: newstore direction

skeptical of any hope of keeping things "simple." Like Martin downthread, most systems I havce seen (filers, ZFS)) make use of a fast, durable commit log and then flex out...something else. -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 4

Re: nfsv41 over AF_VSOCK (nfs-ganesha)

Hi Bruce, -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-707-0660 fax. 734-769-8938 cel. 734-216-5309 - Original Message - > From: "J. Bruce Fields" <bfie...@redhat.

Re: nfsv41 over AF_VSOCK (nfs-ganesha)

Hi Bruce, -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-707-0660 fax. 734-769-8938 cel. 734-216-5309 - Original Message - > From: "J. Bruce Fields" <bfie...@redhat.

nfsv41 over AF_VSOCK (nfs-ganesha)

arf-4" ../src in ganesha.conf, add "nfsvsock" to Protocols list in EXPORT block 5. mount in guest w/nfs41: (e.g., in fstab) 2:// /vsock41 nfs noauto,soft,nfsvers=4.1,sec=sys,proto=vsock,clientaddr=4,rsize=1048576,wsize=1048576 0 0 If you try this, send feedback. Thanks! Matt -

Re: libcephfs invalidate upcalls

Hi, -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 - Original Message - > From: "John Spray" <jsp...@redhat.com> &

libcephfs invalidate upcalls

and dentry invalidates, so I extended the model slightly to hook cap revocation, feedback appreciated. g...@github.com:linuxbox2/ceph.git , branch invalidate g...@github.com:linuxbox2/nfs-ganesha.git , branch ceph-invalidates thanks, Matt -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suit

Re: About Fio backend with ObjectStore API

It would be worth exploring async, sure. matt -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 - Original Message - > From: "Ja

Re: Ceph Hackathon: More Memory Allocator Testing

We've frequently run fio + libosd (cohort ceph-osd linked as a library) with jemalloc preloaded, without problems. Matt -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-761-4689 fax. 734-769

handle-based object store

debating in Oregon 8. thread-local caches of collections and objects above the OS interface that appeared to be a big help in IOPs work ok, apparently we're on for 11:00 am pst--I'll send an invite Matt -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http

Re: Ceph Hackathon: More Memory Allocator Testing

Jemalloc 4.0 seems to have some shiny new capabilities, at least. Matt -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 - Original Message

Re: Async reads, sync writes, op thread model discussion

that encapsulate small, then larger pieces of the work pipeline My .05. Matt -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 - Original Message

Re: bufferlist allocation optimization ideas

We explored a number of these ideas. We have a few branches that might be picked over. Having said that, our feeling was that the generality to span shared and non-shared cases transparently has cost in the unmarked case. Other aspects of the buffer indirection are essential (e.g., Accelio

Re: [michigan-eng] cmake and gitbuilder, juntos

Message - From: Matt Benjamin mbenja...@redhat.com To: michigan-...@redhat.com Sent: Monday, August 3, 2015 5:21:38 PM Subject: [michigan-eng] cmake and gitbuilder, juntos (04:53:04 PM) mattbenjamin: gitbuilder doesn't understand cmake; I heard someone (sam?) talk about gitbiulder eol--but that's

Re: Cluster Network Public Network w.r.t XIO ?

Hi Neo, On our formerly-internal firefly-based branch, what we did was create additional Messenger instances ad infinitum, which at least let you do this, but it's not what anybody wanted for upstream or long-term. What's upstream now doesn't let you IIRC describe that. The rdma_local