Sorry this sucks guys - when is it going to get fixed? Ubuntu 20.04 also
stopped working for me since the transition to snap happend - all
kerberos and gssapi authentications no longer work
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
Sorry this sucks guys - when is it going to get fixed? Ubuntu 20.04 also
stopped working for me since the transition to snap happend - all
kerberos and gssapi authentications no longer work
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Hi Lindays,
Am 29.06.20 um 15:37 schrieb Lindsay Mathieson:
> Nautilus - Bluestore OSD's created with everything on disk. Now I have
> some spare SSD's - can I move the location of the existing WAL and/or DB
> to SSD partitions without recreating the OSD?
>
> I suspect not - saw emails from
HI Ben,
yes we have the same issues and switched to seagate for those reasons.
you can fix at least a big part of it by disabling the write cache of
those drives - generally speaking it seems the toshiba firmware is broken.
I was not able to find a newer one.
Greets,
Stefan
Am 24.06.20 um
;
> Thanks,
>
> Igor
>
>
> On 5/11/2020 9:44 AM, Stefan Priebe - Profihost AG wrote:
>> Hi Igor,
>>
>> where to post the logs?
>>
>> Am 06.05.20 um 09:23 schrieb Stefan Priebe - Profihost AG:
>>> Hi Igor,
>>>
>>> Am 05.
Hi Igor,
where to post the logs?
Am 06.05.20 um 09:23 schrieb Stefan Priebe - Profihost AG:
> Hi Igor,
>
> Am 05.05.20 um 16:10 schrieb Igor Fedotov:
>> Hi Stefan,
>>
>> so (surprise!) some DB access counters show a significant difference, e.g.
t.sum: 0.003866224
kv_sync_lat.sum: 2.667407139
bytes_written_sst: 34904457
> If that's particularly true for "kv_flush_lat" counter - please rerun with
> debug-bluefs set to 20 and collect OSD logs for both cases
Yes it's still true for kv_flush_lat - see above. Where to upload
cause ill effects on osd.
Please adjust 'osd_bench_small_size_max_iops' with a higher value if you
wish to use a higher 'count'.
Stefan
>
>
> Thanks,
>
> Igor
>
> On 4/28/2020 8:42 PM, Stefan Priebe - Profihost AG wrote:
>> HI Igor,
>>
>> but the performance
KiB in 10.7454 sec at 1.1 MiB/sec 279
IOPS
both baked by the same SAMSUNG SSD as block.db.
Greets,
Stefan
Am 28.04.20 um 19:12 schrieb Stefan Priebe - Profihost AG:
> Hi Igore,
> Am 27.04.20 um 15:03 schrieb Igor Fedotov:
>> Just left a comment at https://tracker.ceph.com/
grate to do actual migration.
>
> And I think that's the root cause for the above ticket.
perfect - this removed all spillover in seconds.
Greets,
Stefan
> Thanks,
>
> Igor
>
> On 4/24/2020 2:37 PM, Stefan Priebe - Profihost AG wrote:
>> No not a standalone Wal I wan
>
> Thanks,
>
> Igor
>
>
>
> On 4/24/2020 12:32 PM, Stefan Priebe - Profihost AG wrote:
>> Hi Igor,
>>
>> there must be a difference. I purged osd.0 and recreated it.
>>
>> Now it gives:
>> ceph tell osd.0 bench
>> {
>&
I presume all the benchmark results are persistent, i.e.
> you can see the same results for multiple runs.
Yes I did 10 runs for each posted benchmark.
Thanks,
Stefan
>
>
> Thanks,
>
> Igor
>
>
>
>> On 4/24/2020 12:32 PM, Stefan Priebe - Profihost AG
t;
>
> On 4/24/2020 1:58 PM, Stefan Priebe - Profihost AG wrote:
>> Is Wal device missing? Do I need to run bluefs-bdev-new-db and Wal?
>>
>> Greets,
>> Stefan
>>
>>> Am 24.04.2020 um 11:32 schrieb Stefan Priebe - Profihost AG
>>> :
>>&
Is Wal device missing? Do I need to run bluefs-bdev-new-db and Wal?
Greets,
Stefan
> Am 24.04.2020 um 11:32 schrieb Stefan Priebe - Profihost AG
> :
>
> Hi Igor,
>
> there must be a difference. I purged osd.0 and recreated it.
>
> Now it gives:
uot;iops": 31.389961354303033
}
What's wrong wiht adding a block.db device later?
Stefan
Am 23.04.20 um 20:34 schrieb Stefan Priebe - Profihost AG:
Hi,
if the OSDs are idle the difference is even more worse:
# ceph tell osd.0 bench
{
"bytes_written": 1073741824,
t;: 16.626931034761871
}
# ceph tell osd.38 bench
{
"bytes_written": 1073741824,
"blocksize": 4194304,
"elapsed_sec": 6.890398517004,
"bytes_per_sec": 155831599.77624846,
"iops": 37.153148597776521
}
Stefan
Am 23.04.20 um 14:39 schr
ld
give the same performance from their specs. The only other difference is
that OSD 36 was directly created with the block.db device (Nautilus
14.2.7) and OSD 0 (14.2.8) does not.
Stefan
On 4/23/2020 8:35 AM, Stefan Priebe - Profihost AG wrote:
Hello,
is there anything else needed beside running:
ceph-b
Hello,
is there anything else needed beside running:
ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-${OSD}
bluefs-bdev-new-db --dev-target /dev/vgroup/lvdb-1
I did so some weeks ago and currently i'm seeing that all osds
originally deployed with --block-db show 10-20% I/O waits while all
ZZE-IfWd-Rtxn-0eVW-kTuQmj
Mit freundlichen Grüßen
Stefan Priebe
Bachelor of Science in Computer Science (BSCS)
Vorstand (CTO)
---
Profihost AG
Expo Plaza 1
30539 Hannover
Deutschland
Tel.: +49 (511) 5151 8181 | Fax.: +49 (511) 5151 8282
URL: http://www.profihost.
Greets,
Stefan
>
> On 4/21/2020 4:02 PM, Stefan Priebe - Profihost AG wrote:
>> Hi there,
>>
>> i've a bunch of hosts where i migrated HDD only OSDs to hybird ones
>> using:
>> sudo -E -u ceph -- bash -c 'ceph-bluestore-tool --path
>> /var/lib/ceph/osd/ceph-${OSD}
Hi there,
i've a bunch of hosts where i migrated HDD only OSDs to hybird ones using:
sudo -E -u ceph -- bash -c 'ceph-bluestore-tool --path
/var/lib/ceph/osd/ceph-${OSD} bluefs-bdev-new-db --dev-target
/dev/bluefs_db1/db-osd${OSD}'
while this worked fine and each OSD was running fine.
It looses
Hello,
while playing with an AMD Epyc System and Qemu 3.1.1.1 i was wondering
about the CPU Flags needed for full meltdown / spectre mitigation.
First i added the following patch to Qemu to add STIBP support:
>From 60345b5c0819975b6b4e3a531281aaad724dbcf0 Mon Sep 17 00:00:00 2001
From: Eduardo
Hello,
while playing with an AMD Epyc System and Qemu 3.1.1.1 i was wondering
about the CPU Flags needed for full meltdown / spectre mitigation.
First i added the following patch to Qemu to add STIBP support:
>From 60345b5c0819975b6b4e3a531281aaad724dbcf0 Mon Sep 17 00:00:00 2001
From: Eduardo
Hello,
is there any way to reset deep-scrubbed time for pgs?
The cluster was accidently in state nodeep-scrub and is now unable to
deep scrub fast enough.
Is there any way to force mark all pgs as deep scrubbed to start from 0
again?
Greets,
Stefan
Am 04.03.20 um 16:02 schrieb Wido den Hollander:
>
>
> On 3/4/20 3:49 PM, Lars Marowsky-Bree wrote:
>> On 2020-03-04T15:44:34, Wido den Hollander wrote:
>>
>>> I understand what you are trying to do, but it's a trade-off. Endless
>>> snapshots are also a danger because bit-rot can sneak in
Am 04.03.20 um 15:49 schrieb Lars Marowsky-Bree:
> On 2020-03-04T15:44:34, Wido den Hollander wrote:
>
>> I understand what you are trying to do, but it's a trade-off. Endless
>> snapshots are also a danger because bit-rot can sneak in somewhere which
>> you might not notice.
>>
>> A fresh
Am 04.03.20 um 15:44 schrieb Wido den Hollander:
>
>
> On 3/3/20 8:46 PM, Stefan Priebe - Profihost AG wrote:
>> Hello,
>>
>> does anybody know whether there is any mechanism to make sure an image
>> looks like the original after an import-diff?
>>
>
;
>
> On Wed, Mar 4, 2020 at 11:05 AM Stefan Priebe - Profihost AG
> wrote:
>>
>> Hello,
>>
>> is there any way to switch to pg_upmap without triggering heavy
>> rebalancing two times?
>>
>> 1.) happens at:
>> ceph osd crush weig
Hello,
is there any way to switch to pg_upmap without triggering heavy
rebalancing two times?
1.) happens at:
ceph osd crush weight-set rm-compat
2.) happens after running the balancer in pg_upmap mode
Greets,
Stefan
___
ceph-users mailing list --
n an rbd export on
the source and target snapshot everytime to compare hashes? Which is
slow if you talk about 100's of terrabytes of data isn't it?
Stefan
>
> Regards,
>
> [1] https://github.com/JackSlateur/backurne
>
> On 3/3/20 8:46 PM, Stefan Priebe - Profihost AG wrote:
>>
Hello,
does anybody know whether there is any mechanism to make sure an image
looks like the original after an import-diff?
While doing ceph backups on another ceph cluster i currently do a fresh
import every 7 days. So i'm sure if something went wrong with
import-diff i have a fresh one every 7
Am 03.03.20 um 15:34 schrieb Rafał Wądołowski:
> Stefan,
>
> What version are you running?
14.2.7
> You wrote "Ceph automatically started to
> migrate all date from the hdd to the ssd db device", is that normal auto
> compaction or ceph developed a trigger to do it?
normal after running
Am 03.03.20 um 08:38 schrieb Thomas Lamprecht:
> Hi,
>
> On 3/3/20 8:01 AM, Stefan Priebe - Profihost AG wrote:
>> does anybody have a guide to build ceph Nautilus for Debian stretch? I
>> wasn't able to find a backported gcc-8 for stretch.
>
> That's because a gc
Nobody who has an idea? Ceph automatically started to migrate all date
from the hdd to the ssd db device but has stopped at 128kb on nearly all
osds.
Greets,
Stefan
Am 02.03.20 um 10:32 schrieb Stefan Priebe - Profihost AG:
> Hello,
>
> i added a db device to my osds running nautilu
Hello list,
does anybody have a guide to build ceph Nautilus for Debian stretch? I
wasn't able to find a backported gcc-8 for stretch.
Otherwise i would start one.
Greets,
Stefan
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an
osd creation a ssd device.
Greets,
Stefan
>
> Reed
>
>> On Mar 2, 2020, at 3:32 AM, Stefan Priebe - Profihost AG
>> mailto:s.pri...@profihost.ag>> wrote:
>>
>> Hello,
>>
>> i added a db device to my osds running nautilus. The DB data migratet
&
Hello,
i added a db device to my osds running nautilus. The DB data migratet
over some days from the hdd to ssd (db device).
But now it seems all are stuck at:
# ceph health detail
HEALTH_WARN BlueFS spillover detected on 8 OSD(s)
BLUEFS_SPILLOVER BlueFS spillover detected on 8 OSD(s)
osd.0
negative index starting at - up to -1 as a prefix.
>
> -1> 2020-01-16 01:10:13.404090 7f3350a14700 -1 rocksdb:
>
>
> It would be great If you share several log snippets for different
> crashes containing these last 1 lines.
>
>
> Thanks,
>
> Igor
>
ed log level and dumps
> them on crash with negative index starting at - up to -1 as a prefix.
>
> -1> 2020-01-16 01:10:13.404090 7f3350a14700 -1 rocksdb:
>
>
> It would be great If you share several log snippets for different
> crashes containing these last 100
=
0x7f8001cc45c881217262'd_data.4303206b8b4567.9632!='0xfffe'o'
Value size = 510)
on the right size i always see 0xfffe on all
failed OSDs.
greets,
Stefan
Am 19.01.20 um 14:07 schrieb Stefan Priebe - Profihost AG:
> Yes, except that this happ
times this might
> provide some hints.
>
>
> Thanks,
>
> Igor
>
>
>> On 1/17/2020 2:30 PM, Stefan Priebe - Profihost AG wrote:
>> HI Igor,
>>
>>> Am 17.01.20 um 12:10 schrieb Igor Fedotov:
>>> hmmm..
>>>
>>> Just in ca
start collecting failure-related information
> (including but not limited to failure logs, perf counter dumps, system
> resource reports etc) for future analysis.
>
>
>
> On 1/16/2020 11:58 PM, Stefan Priebe - Profihost AG wrote:
>> Hi Igor,
>>
>> answers inlin
;
> Igor
>
>
>
> On 1/16/2020 10:04 PM, Stefan Priebe - Profihost AG wrote:
>> Hi Igor,
>>
>> ouch sorry. Here we go:
>>
>> -1> 2020-01-16 01:10:13.404090 7f3350a14700 -1 rocksdb:
>> submit_transaction error: Corruption: block checksu
...
>
>
> Thanks,
>
> Igor
>
> On 1/16/2020 11:56 AM, Stefan Priebe - Profihost AG wrote:
>> Hello,
>>
>> does anybody know a fix for this ASSERT / crash?
>>
>> 2020-01-16 02:02:31.316394 7f8c3f5ab700 -1
>> /build/ceph/src/os/bluestore/BlueStore
Hello,
does anybody know a fix for this ASSERT / crash?
2020-01-16 02:02:31.316394 7f8c3f5ab700 -1
/build/ceph/src/os/bluestore/BlueStore.cc: In function 'void
BlueStore::_kv_sync_thread()' thread 7f8c3f5ab700 time 2020-01-16
02:02:31.304993
/build/ceph/src/os/bluestore/BlueStore.cc: 8808:
Hello,
does anybody have real live experience with externel block db?
Greets,
Stefan
Am 13.01.20 um 08:09 schrieb Stefan Priebe - Profihost AG:
> Hello,
>
> i'm plannung to split the block db to a seperate flash device which i
> also would like to use as an OSD for erasure cod
ch have a
capacitor. Samsung does not.
The problem is that Ceph sends a lot of flush commands which slows down
drives without capacitor.
You can make linux to ignore those userspace requests with the following
command:
echo "temporary write through" >
/sys/block/sdX/device/scsi_disk/*/
Hello,
i'm plannung to split the block db to a seperate flash device which i
also would like to use as an OSD for erasure coding metadata for rbd
devices.
If i want to use 14x 14TB HDDs per Node
https://docs.ceph.com/docs/master/rados/configuration/bluestore-config-ref/#sizing
recommends a
Hi,
we‘re currently in the process of building a new ceph cluster to backup rbd
images from multiple ceph clusters.
We would like to start with just a single ceph cluster to backup which is about
50tb. Compression ratio of the data is around 30% while using zlib. We need to
scale the backup
ter to sync snapshots once a
day.
Important is pricing, performance todo this task and expansion. We would like
to start with something around just 50tb storage.
Greets,
Stefan
>
>
>> Stefan Priebe - Profihost AG < s.pri...@profihost.ag> hat am 9. Januar 2020
>> um 22:5
or not?
Since we started using ceph we're mostly subscribed to SSDs - so no
knowlege about HDD in place.
Greets,
Stefan
Am 09.01.20 um 16:49 schrieb Stefan Priebe - Profihost AG:
>
>> Am 09.01.2020 um 16:10 schrieb Wido den Hollander :
>>
>>
>>
>>> On 1/9/20 2
> Am 09.01.2020 um 16:10 schrieb Wido den Hollander :
>
>
>
>> On 1/9/20 2:27 PM, Stefan Priebe - Profihost AG wrote:
>> Hi Wido,
>>> Am 09.01.20 um 14:18 schrieb Wido den Hollander:
>>>
>>>
>>> On 1/9/20 2:07 PM, Daniel Aberger -
Hi Wido,
Am 09.01.20 um 14:18 schrieb Wido den Hollander:
>
>
> On 1/9/20 2:07 PM, Daniel Aberger - Profihost AG wrote:
>>
>> Am 09.01.20 um 13:39 schrieb Janne Johansson:
>>>
>>> I'm currently trying to workout a concept for a ceph cluster which can
>>> be used as a target for backups
or not.
>
> This time it reminds the issue shared in this mailing list a while ago by
> Stefan Priebe. The post caption is "Bluestore OSDs keep crashing in
> BlueStore.cc: 8808: FAILED assert(r == 0)"
>
> So first of all I'd suggest to distinguish these issues for now an
33 schrieb Stefan Priebe - Profihost AG:
> Hi,
>
> i'm trying to run the webgui of rabbitmq behind apache proxy while using
> mod_rewrite.
>
> RabbitMQ generates URLs like:
> http://rabbit.example.com/#/queues/%2F/myqueue
>
> but those always generate a 404
>
Hi,
i'm trying to run the webgui of rabbitmq behind apache proxy while using
mod_rewrite.
RabbitMQ generates URLs like:
http://rabbit.example.com/#/queues/%2F/myqueue
but those always generate a 404
What i tried is:
AllowEncodedSlashes NoDecode or Yes
RewriteRule ^/?rabbitmq/(.*)$
l unpatched and 12.2.13 might the first containing this
fix - but no idea of an ETA.
Greets,
Stefan
> Thanks,
>
> Igor
>
> On 9/12/2019 8:20 PM, Stefan Priebe - Profihost AG wrote:
>> Hello Igor,
>>
>> i can now confirm that this is indeed a kernel bug. The issue does n
wapping:
> https://tracker.ceph.com/issues/22464
>
> IMO memory usage worth checking as well...
>
>
> Igor
>
>
> On 8/27/2019 4:52 PM, Stefan Priebe - Profihost AG wrote:
>> see inline
>>
>> Am 27.08.19 um 15:43 schrieb Igor Fedotov:
>>&g
Yes, that works fine! Thanks a lot. Is there any ETA for a release?
Greets,
Stefan
Am 04.09.19 um 22:32 schrieb Michael Biebl:
> Am 04.09.19 um 14:57 schrieb Michael Biebl:
>> Am 04.09.19 um 14:09 schrieb Stefan Priebe - Profihost AG:
>>> Hello,
>>>
>>> c
Yes, that works fine! Thanks a lot. Is there any ETA for a release?
Greets,
Stefan
Am 04.09.19 um 22:32 schrieb Michael Biebl:
> Am 04.09.19 um 14:57 schrieb Michael Biebl:
>> Am 04.09.19 um 14:09 schrieb Stefan Priebe - Profihost AG:
>>> Hello,
>>>
>>> c
Hello,
currently systemd is broken in buster regarding RootDirectory and User.
The issue was fixed in systemd 243 and the relevant commits are
referenced in the specific bug report:
https://github.com/systemd/systemd/issues/12498
Any chance to get this fixed soon? This broke a lot of our
l invalid
> data reads under high memory pressure/swapping:
> https://tracker.ceph.com/issues/22464
We have a current 4.19.X kernel and no memory limit. Mem avail is pretty
constant at 32GB.
Greets,
Stefan
>
> IMO memory usage worth checking as well...
>
>
> Igor
>
>
see inline
Am 27.08.19 um 15:43 schrieb Igor Fedotov:
> see inline
>
> On 8/27/2019 4:41 PM, Stefan Priebe - Profihost AG wrote:
>> Hi Igor,
>>
>> Am 27.08.19 um 14:11 schrieb Igor Fedotov:
>>> Hi Stefan,
>>>
>>> this looks like a dupli
you run fsck for any of broken OSDs? Any reports?
Yes but no reports.
> Any other errors/crashes in logs before these sort of issues happens?
No
> Just in case - what allocator are you using?
tcmalloc
Greets,
Stefan
>
> Thanks,
>
> Igor
>
>
>
> On 8/27/2019 1:0
Hello,
since some month all our bluestore OSDs keep crashing from time to time.
Currently about 5 OSDs per day.
All of them show the following trace:
Trace:
2019-07-24 08:36:48.995397 7fb19a711700 -1 rocksdb: submit_transaction
error: Corruption: block checksum mismatch code = 2 Rocksdb
Hello,
since some month all our bluestore OSDs keep crashing from time to time.
Currently about 5 OSDs per day.
All of them show the following trace:
Trace:
2019-07-24 08:36:48.995397 7fb19a711700 -1 rocksdb: submit_transaction
error: Corruption: block checksum mismatch code = 2 Rocksdb
Hello,
i'm interested if it is possible to livepatch the guest kernel without
reboot.
(host kernel and microcode is patched)
Greets,
Stefan
Am 15.05.19 um 19:54 schrieb Daniel P. Berrangé:
> On Wed, May 15, 2019 at 07:13:56PM +0200, Stefan Priebe - Profihost AG wrote:
>> Hello list,
>>
>> i've updated my host to kernel 4.19.43 and applied the following patch
>> to my qemu 2.12.1:
>> https://bugzilla.
Hello list,
i've updated my host to kernel 4.19.43 and applied the following patch
to my qemu 2.12.1:
https://bugzilla.suse.com/attachment.cgi?id=798722
But my guest running 4.19.43 still says:
Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state
unknown
while the host says:
Am 06.03.19 um 14:08 schrieb Mark Nelson:
>
> On 3/6/19 5:12 AM, Stefan Priebe - Profihost AG wrote:
>> Hi Mark,
>> Am 05.03.19 um 23:12 schrieb Mark Nelson:
>>> Hi Stefan,
>>>
>>>
>>> Could you try running your random write workload a
_cond_wait@@GLIBC_2.3.2 () from
target:/lib/x86_64-linux-gnu/libpthread.so.0
.
Thread 1 "ceph-osd" received signal SIGINT, Interrupt.
0x7f917b6a615f in pthread_cond_wait@@GLIBC_2.3.2 () from
target:/lib/x86_64-linux-gnu/libpthread.so.0
.
Thread 1 "ceph-osd" received signal SIG
Am 05.03.19 um 10:05 schrieb Paul Emmerich:
> This workload is probably bottlenecked by rocksdb (since the small
> writes are buffered there), so that's probably what needs tuning here.
while reading:
Hello list,
while the performance of sequential writes 4k on bluestore is very high
and even higher than filestore i was wondering what i can do to optimize
random pattern as well.
While using:
fio --rw=write --iodepth=32 --ioengine=libaio --bs=4k --numjobs=4
--filename=/tmp/test --size=10G
op_w_process_latency.sum"),
> 1s)/non_negative_derivative(first("op_w_process_latency.avgcount"),1s) FROM
> "ceph" WHERE "host" =~ /^([[host]])$/ AND collection='osd' AND "id" =~
> /^([[osd]])$/ AND $timeFilter GROUP BY time($interval), "host
Hi,
Am 30.01.19 um 08:33 schrieb Alexandre DERUMIER:
> Hi,
>
> here some new results,
> different osd/ different cluster
>
> before osd restart latency was between 2-5ms
> after osd restart is around 1-1.5ms
>
> http://odisoweb1.odiso.net/cephperf2/bad.txt (2-5ms)
>
Hi,
in twitter and other social media channels they're talking about a
current apache 0 day:
https://twitter.com/i/web/status/1087593706444730369
which wasn't handled / isn't currently fixed.
Some details are here:
https://github.com/hannob/apache-uaf
If this is true there will be exploits
ng against and using jemalloc. What happens in this case?
Also i saw now - that 12.2.10 uses 1GB mem max while 12.2.8 uses 6-7GB
Mem (with bluestore_cache_size = 1073741824).
Greets,
Stefan
Am 17.01.19 um 22:59 schrieb Stefan Priebe - Profihost AG:
> Hello Mark,
>
> for whatever reaso
)
That's currently all i know.
Thanks a lot!
Greets,
Stefan
Am 16.01.19 um 20:56 schrieb Stefan Priebe - Profihost AG:
> i reverted the whole cluster back to 12.2.8 - recovery speed also
> dropped from 300-400MB/s to 20MB/s on 12.2.10. So something is really
> broken.
>
> Greets
i reverted the whole cluster back to 12.2.8 - recovery speed also
dropped from 300-400MB/s to 20MB/s on 12.2.10. So something is really
broken.
Greets,
Stefan
Am 16.01.19 um 16:00 schrieb Stefan Priebe - Profihost AG:
> This is not the case with 12.2.8 - it happens with 12.2.9 as well. Af
15:22 schrieb Stefan Priebe - Profihost AG:
> Hello,
>
> while digging into this further i saw that it takes ages until all pgs
> are active. After starting the OSD 3% of all pgs are inactive and it
> takes minutes after they're active.
>
> The log of the OSD is full of:
>
1318356'61576253 active+rec
overing+degraded m=183 snaptrimq=[ec1a0~1,ec808~1]
mbc={255={(2+0)=183,(3+0)=3}}] _update_calc_stats ml 183 upset size 3 up 2
Greets,
Stefan
Am 16.01.19 um 09:12 schrieb Stefan Priebe - Profihost AG:
> Hi,
>
> no ok it was not. Bug still present. It was only workin
Hi,
Am 15.01.19 um 08:19 schrieb Stefan Priebe - Profihost AG:
>
> Am 15.01.19 um 08:15 schrieb Fabian Grünbichler:
>> On Mon, Jan 14, 2019 at 11:04:29AM +0100, Stefan Priebe - Profihost AG wrote:
>>> Hello,
>>>
>>> today i was wondering about so
Hi,
no ok it was not. Bug still present. It was only working because the
osdmap was so far away that it has started backfill instead of recovery.
So it happens only in the recovery case.
Greets,
Stefan
Am 15.01.19 um 16:02 schrieb Stefan Priebe - Profihost AG:
>
> Am 15.01.19 um 12:45 s
Am 15.01.19 um 12:45 schrieb Marc Roos:
>
> I upgraded this weekend from 12.2.8 to 12.2.10 without such issues
> (osd's are idle)
it turns out this was a kernel bug. Updating to a newer kernel - has
solved this issue.
Greets,
Stefan
> -Original Message-----
> From
Hello list,
i also tested current upstream/luminous branch and it happens as well. A
clean install works fine. It only happens on upgraded bluestore osds.
Greets,
Stefan
Am 14.01.19 um 20:35 schrieb Stefan Priebe - Profihost AG:
> while trying to upgrade a cluster from 12.2.8 to 12.2.10
Am 15.01.19 um 08:15 schrieb Fabian Grünbichler:
> On Mon, Jan 14, 2019 at 11:04:29AM +0100, Stefan Priebe - Profihost AG wrote:
>> Hello,
>>
>> today i was wondering about some disk images while the vm was deleted.
>>
>> Inspecting the task history i found this
Hi Paul,
Am 14.01.19 um 21:39 schrieb Paul Emmerich:
> What's the output of "ceph daemon osd. status" on one of the OSDs
> while it's starting?
{
"cluster_fsid": "b338193d-39e0-40e9-baba-4965ef3868a3",
"osd_fsid": "d95d0e3b-7441-4ab0-869c-fe0551d3bd52",
"whoami": 2,
"state":
Hi,
while trying to upgrade a cluster from 12.2.8 to 12.2.10 i'm experience
issues with bluestore osds - so i canceled the upgrade and all bluestore
osds are stopped now.
After starting a bluestore osd i'm seeing a lot of slow requests caused
by very high read rates.
Device: rrqm/s
Hello,
today i was wondering about some disk images while the vm was deleted.
Inspecting the task history i found this log:
trying to acquire cfs lock 'storage-cephstoroffice' ...
trying to acquire cfs lock 'storage-cephstoroffice' ...
trying to acquire cfs lock 'storage-cephstoroffice' ...
)
Am 09.01.19 um 12:00 schrieb Brian Candler:
> On 09/01/2019 10:51, Stefan Priebe - Profihost AG wrote:
>> Real test is / was:
>> mydomain.multi.uribl.rblserver.de-nserver.de
>
> I see a SERVFAIL here, not an NXDOMAIN. Do you get the same?
>
> $ dig mydoma
Hi,
Am 09.01.19 um 09:53 schrieb Nico CARTRON:
> On 09-Jan-2019 09:39 CET, wrote:
>
>> Hi Nico,
>>
>> Am 09.01.19 um 09:33 schrieb Nico CARTRON:
>>> Hi Stefan,
>>>
>>> On 09-Jan-2019 09:19 CET, wrote:
>>>
Dear List,
i'm trying to get max-negative-ttl to work but i can't.
Hi Nico,
Am 09.01.19 um 09:33 schrieb Nico CARTRON:
> Hi Stefan,
>
> On 09-Jan-2019 09:19 CET, wrote:
>
>> Dear List,
>>
>> i'm trying to get max-negative-ttl to work but i can't.
>>
>> # dpkg -s pdns-recursor | grep Version
>> Version: 4.1.8-1pdns.stretch
>>
>> # grep max-negative-ttl
Dear List,
i'm trying to get max-negative-ttl to work but i can't.
# dpkg -s pdns-recursor | grep Version
Version: 4.1.8-1pdns.stretch
# grep max-negative-ttl /etc/powerdns/recursor.conf
max-negative-ttl=30
# dig -t A unknowndomainxyz.multi.hiddendomain.de
...
;; ->>HEADER<<- opcode: QUERY,
Hi Alexandre,
Am 08.01.19 um 21:55 schrieb Alexandre DERUMIER:
>>> But, file_set_contents - which save_clusterfw_conf uses - does this
>>> already[0],
>>> so maybe this is the "high-level fuse rename isn't atomic" bug again...
>>> May need to take a closer look tomorrow.
>
> mmm, ok.
>
> In
Hello,
since upgrading to PVE 5 i'm seeing the following error on a regular
basis - while stress testing migration (doing 100-200 migrations in a row):
2018-10-23 13:54:42 migration speed: 384.00 MB/s - downtime 113 ms
2018-10-23 13:54:42 migration status: completed
2018-10-23 13:54:42 ERROR:
sks.
> You might need to modify some bluestore settings to speed up the time it
> takes to peer or perhaps you might just be underpowering the amount of
> OSD disks you're trying to do and your servers and OSD daemons are going
> as fast as they can.
> On Sat, Oct 13, 2018 at 4:0
Am 17.10.18 um 10:14 schrieb Christoph Hellwig:
> On Tue, Oct 16, 2018 at 07:33:53PM +0200, Stefan Priebe - Profihost AG wrote:
>> Hi David,
>>
>> can you give as any hint? We're running aroud 120 Adaptec Controllers
>> and i don't want to replace them all...
Hi David,
can you give as any hint? We're running aroud 120 Adaptec Controllers
and i don't want to replace them all...
Greets,
Stefan
Am 27.09.2018 um 14:23 schrieb Stefan Priebe - Profihost AG:
>
> Am 27.09.2018 um 12:59 schrieb Emmanuel Florac:
>> Le Wed, 19 Sep 2018 08
tat shows:
sdi 77,00 0,00 580,00 97,00 511032,00 972,00
1512,5714,88 22,05 24,576,97 1,48 100,00
so it reads with 500MB/s which completely saturates the osd. And it does
for > 10 minutes.
Greets,
Stefan
Am 13.10.2018 um 21:29 schrieb Stefan Priebe - Profih
tat shows:
sdi 77,00 0,00 580,00 97,00 511032,00 972,00
1512,5714,88 22,05 24,576,97 1,48 100,00
so it reads with 500MB/s which completely saturates the osd. And it does
for > 10 minutes.
Greets,
Stefan
Am 13.10.2018 um 21:29 schrieb Stefan Priebe - Profih
1 - 100 of 3170 matches
Mail list logo
