On 2015-06-01T15:41:05, Steffen Weißgerber wrote:
> Hi,
>
> I'm searching for actual packages for SLES11 SP3.
>
> Via SMT-Updateserver it seems that there's only Version 0.80.8 available. Are
> there
> other package sources available (at least for Giant)?
Hi Steffen,
we have only released th
On 2015-06-02T15:40:54, gjprabu wrote:
> Hi Team,
>
> We are newly using ceph with two OSD and two clients, our requirement
> is when we write date through clients it should see in another client also,
> storage is mounted using rbd because we running git clone with large amount
> of s
On 2015-06-02T17:23:58, gjprabu wrote:
> Hi Lars,
>
>We installed centos in client machines with kernel version is 3.10
> which is rbd supported modules. Now installed ocsfs2-tools and formated but
> mount through error. Please check below.
You need to configure the ocfs2 cluster
On 2015-06-04T12:42:42, David Burley wrote:
> Are there any safety/consistency or other reasons we wouldn't want to try
> using an external XFS log device for our OSDs? I realize if that device
> fails the filesystem is pretty much lost, but beyond that?
I think with the XFS journal on the same
On 2015-07-09T14:05:55, David Burley wrote:
> Converted a few of our OSD's (spinners) over to a config where the OSD
> journal and XFS journal both live on an NVMe drive (Intel P3700). The XFS
> journal might have provided some very minimal performance gains (3%,
> maybe). Given the low gains, we
On 2015-07-10T15:20:23, Jacek Jarosiewicz wrote:
> We have tried both - you can see performance gain, but we finally went
> toward ceph cache tier. It's much more flexible and gives similar gains in
> terms of performance.
>
> Downside to bcache is that you can't use it on a drive that already h
On 2015-11-04T14:30:56, Hugo Slabbert wrote:
> Sure. My post was not intended to say that iSCSI over RBD is *slow*, just
> that it scales differently than native RBD client access.
>
> If I have 10 OSD hosts with a 10G link each facing clients, provided the OSDs
> can saturate the 10G links, I
On 2016-07-01T13:04:45, mq wrote:
Hi MQ,
perhaps the upstream list is not the best one to discuss this. SUSE
includes adjusted backports for the iSCSI functionality that upstream
does not; very few people here are going to be intimately familiar with
the code you're running. If you're evaluating
On 2016-07-01T17:18:19, Christian Balzer wrote:
> First off, it's somewhat funny that you're testing the repackaged SUSE
> Ceph, but asking for help here (with Ceph being owned by Red Hat).
*cough* Ceph is not owned by RH. RH acquired the InkTank team and the
various trademarks, that's true (and
On 2016-07-01T19:11:34, Nick Fisk wrote:
> To summarise,
>
> LIO is just not working very well at the moment because of the ABORT Tasks
> problem, this will hopefully be fixed at some point. I'm not sure if SUSE
> works around this, but see below for other pain points with RBD + ESXi + iSCSI
On 2017-06-22T00:51:38, Blair Bethwaite wrote:
> I'm doing some work to evaluate the risks involved in running 2r storage
> pools. On the face of it my naive disk failure calculations give me 4-5
> nines for a 2r pool of 100 OSDs (no copyset awareness, i.e., secondary disk
> failure based purely
On 2017-06-26T11:28:36, Ashley Merrick wrote:
> With the EC Overwite support, if currently running behind a cache tier in
> Jewel will the overwrite still be of benefit through the cache tier and
> remove the need to promote the full block to make any edits?
>
> Or we better totally removing t
On 2017-06-30T16:48:04, Sage Weil wrote:
> > Simply disabling the tests while keeping the code in the distribution is
> > setting up users who happen to be using Btrfs for failure.
>
> I don't think we can wait *another* cycle (year) to stop testing this.
>
> We can, however,
>
> - prominentl
On 2017-07-14T14:12:08, Sage Weil wrote:
> > Any thoughts on how to mitigate this, or on whether I got this all wrong and
> > am missing a crucial detail that blows this wall of text away, please let me
> > know.
> I don't know; the requirement that mons be upgraded before OSDs doesn't
> seem th
On 2017-07-14T10:34:35, Mike Lowe wrote:
> Having run ceph clusters in production for the past six years and upgrading
> from every stable release starting with argonaut to the next, I can honestly
> say being careful about order of operations has not been a problem.
This requirement did not e
On 2017-07-14T15:18:54, Sage Weil wrote:
> Yes, but how many of those clusters can only upgrade by updating the
> packages and rebooting? Our documented procedures have always recommended
> upgrading the packages, then restarting either mons or osds first and to
> my recollection nobody has c
On 2017-09-06T15:23:34, Sage Weil wrote:
Hi Sage,
thanks for kicking off this discussion - after the L experience, it was
on my hot list to talk about too.
I do agree that we need predictable releases more than feature-rich
releases. Distributors like to plan, but that's not a reason. However,
On 2017-10-04T21:46:27, Sage Weil wrote:
> > After further discussion we are targetting 9 months for Mimic 13.2.0:
> >
> > - Mar 16, 2018 feature freeze
> > - May 1, 2018 release
> >
> > Upgrades for Mimic will be from Luminous only (we've already made that a
> > required stop), but we plan
On 2017-11-08T21:41:41, Sage Weil wrote:
> Who is running nfs-ganesha's FSAL to export CephFS? What has your
> experience been?
>
> (We are working on building proper testing and support for this into
> Mimic, but the ganesha FSAL has been around for years.)
We use it currently, and it works
On 2018-02-06T13:00:59, Kai Wagner wrote:
> I had the idea to use a RBD device as the SBD device for a pacemaker
> cluster. So I don't have to fiddle with multipathing and all that stuff.
> Have someone already tested this somewhere and can tell how the cluster
> reacts on this?
SBD should work
On 2016-10-17T13:37:29, Maged Mokhtar wrote:
Hi Maged,
glad to see our patches caught your attention. You're aware that they
are being upstreamed by David Disseldorp and Mike Christie, right? You
don't have to uplift patches from our backported SLES kernel ;-)
Also, curious why you based this o
On 2016-10-17T15:31:31, Maged Mokhtar wrote:
> This is our first beta version, we do not support cache tiering. We
> definitely intend to support it.
Cache tiering in Ceph works for this use case. I assume you mean in
your UI?
Though we all are waiting for Luminous to do away with the need for
On 2016-10-18T00:06:57, Erick Perez - Quadrian Enterprises
wrote:
> Is EC in the roadmap for CEPH? Cant seem to find it. My question is because
> "all others" (Nutanix, Hypergrid) do EC storage for VMs as the default way
> of storage. It seems EC in ceph (as of Sept 2016) is considered by many
>
On 2016-10-18T11:36:42, Christian Balzer wrote:
> > Cache tiering in Ceph works for this use case. I assume you mean in
> > your UI?
> May well be, but Oliver suggested that cache-tiering is not supported with
> Hammer (0.94.x), which it most certainly is.
Right, we've got some success stories o
On 2016-10-18T12:46:48, John Spray wrote:
> I've suggested a solution here:
> http://tracker.ceph.com/issues/17604
>
> This is probably going to be a bit of a subjective thing in terms of
> whether people find it useful or find it to be annoying noise, so I'd
> be interested in feedback from peo
On 2018-08-29T01:13:24, Sage Weil wrote:
Most excellent! Welcome, Mike!
I look forward to working with you.
Regards,
Lars
--
Architect SDS, Distinguished Engineer
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
"Architects should open possib
On 2018-02-28T02:38:34, Patrick Donnelly wrote:
> I think it will be necessary to reduce the actives to 1 (max_mds -> 1;
> deactivate other ranks), shutdown standbys, upgrade the single active,
> then upgrade/start the standbys.
>
> Unfortunately this didn't get flagged in upgrade testing. Thank
On 2018-03-02T15:24:29, Joshua Chen wrote:
> Dear all,
> I wonder how we could support VM systems with ceph storage (block
> device)? my colleagues are waiting for my answer for vmware (vSphere 5) and
> I myself use oVirt (RHEV). the default protocol is iSCSI.
Lean on VMWare to stop being diff
On 2018-03-14T06:57:08, Patrick Donnelly wrote:
> Yes. But the real outcome is not "no MDS [is] active" but "some or all
> metadata I/O will pause" -- and there is no avoiding that. During an
> MDS upgrade, a standby must take over the MDS being shutdown (and
> upgraded). During takeover, metada
Hi all,
so, I'm wondering right now (with some urgency, ahem) how to make RBD on
EC pools faster without resorting to cache tiering.
In a replicated pool, we had some success with RBD striping.
I wonder if it would be possible to align RBD stripe-unit with the EC
chunk size ...?
Is that worth p
On 2017-05-15T15:21:47, Danny Al-Gaaf wrote:
> What about moving the event to the next OpenStack Summit in Sydney, let
> say directly following the Summit. Not sure how many people already plan
> to go to Sydney from the Ceph Community, but this way the 10-20 h flight
> (depending on your locatio
On 2017-06-16T20:09:04, Gregory Farnum wrote:
> There's a lot going into this release, and things keep popping up. I
> suspect it'll be another month or two, but I doubt anybody is capable of
> giving a more precise date. :/ The downside of giving up on train
> releases...
What's still outstandi
On 2019-06-26T14:45:31, Sage Weil wrote:
Hi Sage,
I think that makes sense. I'd have preferred the Oct/Nov target, but
that'd have made Octopus quite short.
Unsure whether freezing in December with a release in March is too long
though. But given how much people scramble, setting that as a goal
Morning all,
since Luminous/Mimic, Ceph supports allow_ec_overwrites. However, this has a
performance impact that looks even worse than what I'd expect from a
Read-Modify-Write cycle.
https://ceph.com/community/new-luminous-erasure-coding-rbd-cephfs/ also
mentions that the small writes would read
On 2019-07-08T12:25:30, Dan van der Ster wrote:
> Is there a specific bench result you're concerned about?
We're seeing ~5800 IOPS, ~23 MiB/s on 4 KiB IO (stripe_width 8192) on a
pool that could do 3 GiB/s with 4M blocksize. So, yeah, well, that is
rather harsh, even for EC.
> I would think tha
On 2019-07-08T14:36:31, Maged Mokhtar wrote:
Hi Maged,
> Maybe not related, but we find with rbd, random 4k write iops start very low
> at first for a new image and then increase over time as we write. If we
> thick provision the image it work does not show this. This happens on random
> small b
On 2019-07-08T19:37:13, Paul Emmerich wrote:
> object_map can be a bottleneck for the first write in fresh images
We're working with CephFS here.
--
SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG
Nürnberg)
"Architects should open possibilities and not determi
On 2019-07-09T16:32:22, Mattia Belluco wrote:
> That of course in my case fails with:
> Error EPERM: cannot set require_min_compat_client to luminous: 29
> connected client(s) look like jewel (missing 0x800); 1
> connected client(s) look like jewel (missing 0x800); add
> -
On 2019-07-09T07:27:28, Frank Schilder wrote:
> Small addition:
>
> This result holds for rbd bench. It seems to imply good performance for
> large-file IO on cephfs, since cephfs will split large files into many
> objects of size object_size. Small-file IO is a different story.
>
> The formu
On 2019-07-10T09:59:08, Lars Täuber wrote:
> Hi everbody!
>
> Is it possible to make snapshots in cephfs writable?
> We need to remove files because of this General Data Protection Regulation
> also from snapshots.
Removing data from existing WORM storage is tricky, snapshots being a
specific
On 2019-07-11T09:46:47, Frank Schilder wrote:
> Striping with stripe units other than 1 is something I also tested. I found
> that with EC pools non-trivial striping should be avoided. Firstly, EC is
> already a striped format and, secondly, striping on top of that with
> stripe_unit>1 will ma
On 2019-07-15T19:08:26, " Drobyshevskiy, Vladimir " wrote:
Hi Vladimir,
is this a replicated or EC pool?
> The cluster itself:
> nautilus
> 6 nodes, 7 SSD with 2 OSDs per SSD (14 OSDs in overall).
You mean 14 OSDs per node, right?
> Each node: 2x Intel Xeon E5-2665 v1 (governor = perf
On 2019-07-16T19:27:32, " Drobyshevskiy, Vladimir " wrote:
> This is a replicated pool with size = 3.
> Is it possible to check this anyhow? ping shows average latency ~0.147 ms
> which is pretty high for IB but might be reasonable (IPoIB).
This means that, barring any other overhead, you're li
On 2019-07-17T08:27:46, John Petrini wrote:
The main problem we've observed is that not all HBAs can just
efficiently and easily pass through disks 1:1. Some of those from a
more traditional server background insist on having some form of
mapping via RAID.
In that case it depends on whether 1 di
On 2019-07-17T11:56:25, Robert LeBlanc wrote:
> So, I see the recommendation for 4% of OSD space for blocks.db/WAL and the
> corresponding discussion regrading the 3/30/300GB vs 6/60/600GB allocation.
>
> How does this change when WAL is seperate from blocks.db?
>
> Reading [0] it seems that 6/
On 2019-07-21T23:51:41, Wei Zhao wrote:
> Hi:
> I found cosbench is a very convenient tool for benchmaring rgw. But
> when I read papers , I found YCSB tool,
> https://github.com/brianfrankcooper/YCSB/tree/master/s3 . It seems
> that this is used for test cloud service , and seems a right too
On 2019-08-01T15:20:19, Matthew Vernon wrote:
> One you don't mention is that multipart uploads break during resharding - so
> if our users are filling up a bucket with many writers uploading multipart
> objects, some of these will fail (rather than blocking) when the bucket is
> resharded.
Is t
On 2019-08-04T13:27:00, Eitan Mosenkis wrote:
> I'm running a single-host Ceph cluster for CephFS and I'd like to keep
> backups in Amazon S3 for disaster recovery. Is there a simple way to
> extract a CephFS snapshot as a single file and/or to create a file that
> represents the incremental diff
On 2019-08-05T07:27:39, Alfredo Daniel Rezinovsky wrote:
There's no massive problem with even MON counts.
As you note, n+2 doesn't really provide added fault tolerance compared
to n+1, so there's no win either. That's fairly obvious.
Somewhat less obvious - since the failure of any additional M
On 2019-09-10T13:36:53, Konstantin Shalygin wrote:
> > So I am correct in 2048 being a very high number and should go for
> > either 256 or 512 like you said for a cluster of my size with the EC
> > Pool of 8+2?
> Indeed. I suggest stay at 256.
Might as well go to 512, but the 2^n is really impo
50 matches
Mail list logo
