Ceph » rbd

From the mailinglist:

Am 18.07.19 um 20:10 schrieb Jason Dillaman:
> On Thu, Jul 18, 2019 at 1:47 PM Marc Schöchlin <ms@256bit.org> wrote:
>>
>> Hello cephers,
>>
>> rbd-nbd crashes in a reproducible way here.
>
> I don't see a crash report in the log below. Is it really crashing or
> is it shutting down? If it is crashing and it's reproducable, can you
> install the debuginfo packages, attach gdb, and get a full backtrace
> of the crash?

I do not get a crash report of rbd-nbd.
I seems that "rbd-nbd" just terminates, and crashes the xfs filesystem because the nbd device is not available anymore.
("rbd nbd ls" shows no mapped device anymore)
>
>
> It seems like your cluster cannot keep up w/ the load and the nbd
> kernel driver is timing out the IO and shutting down. There is a
> "--timeout" option on "rbd-nbd" that you can use to increase the
> kernel IO timeout for nbd.
>
I have also a 36TB XFS (non_ec) volume on this virtual system mapped by krbd which is under really heavy read/write usage.
I never experienced problems like this on this system with similar usage patterns.

The volume which is involved in the problem only handles a really low load and i was capable to create the error situation by using the simple "find . -type f -name "*.sql" -exec ionice -c3 nice -n 20 gzip -v {} \;" command.
I copied and read ~1.5 TB of data to this volume without a problem - it seems that the gzip command provokes a io pattern which leads to the error situation.

As described i use a luminous "12.2.11" client which does not support that "--timeout" option (btw. a backport would be nice).
Our ceph system runs with a heavy write load, therefore we already set a 60 seconds timeout using the following code:
(https://github.com/OnApp/nbd-kernel_mod/blob/master/nbd_set_timeout.c)

We have ~500 heavy load rbd-nbd devices in our xen cluster (rbd-nbd 12.2.5, kernel 4.4.0+10, centos clone) and ~20 high load krbd devices (kernel 4.15.0-45, ubuntu 16.04) - we never experienced problems like this.
We only experience problems like this with rbd-nbd > 12.2.5 on ubuntu 16.04 (kernel 4.15) or ubuntu 18.04 (kernel 4.15) with erasure encoding or without.

Regards
Marc

Here is the end of `grep rbd-nbd:` from the attached log:

2019-07-18 14:51:53.936995 7fffbffff700 20 rbd-nbd: [3500000000000000 FLUSH 0~0 0]: start
2019-07-18 14:51:53.937072 7fffbffff700 20 rbd-nbd: reader_entry: waiting for nbd request
2019-07-18 14:51:53.960371 7fffcf7fe700 20 rbd-nbd: aio_callback: [3300000000000000 READ 21b387f3000~20000 0]
2019-07-18 14:51:53.960414 7fffbf7fe700 20 rbd-nbd: writer_entry: got: [3300000000000000 READ 21b387f3000~20000 0]
2019-07-18 14:51:53.960604 7fffbf7fe700 20 rbd-nbd: [3300000000000000 READ 21b387f3000~20000 0]: finish
2019-07-18 14:51:53.960622 7fffbf7fe700 20 rbd-nbd: writer_entry: waiting for io request
2019-07-18 14:51:53.961537 7fffcf7fe700 20 rbd-nbd: aio_callback: [3400000000000000 READ 21b38813000~20000 0]
2019-07-18 14:51:53.961559 7fffbf7fe700 20 rbd-nbd: writer_entry: got: [3400000000000000 READ 21b38813000~20000 0]
2019-07-18 14:51:53.961698 7fffbf7fe700 20 rbd-nbd: [3400000000000000 READ 21b38813000~20000 0]: finish
2019-07-18 14:51:53.961704 7fffbf7fe700 20 rbd-nbd: writer_entry: waiting for io request
2019-07-18 14:51:53.967587 7fffbffff700 20 rbd-nbd: [3400000000000000 READ 21b38833000~20000 0]: start
2019-07-18 14:51:53.967628 7fffbffff700 20 rbd-nbd: reader_entry: waiting for nbd request
2019-07-18 14:51:53.971134 7fffcf7fe700 20 rbd-nbd: aio_callback: [3400000000000000 READ 21b38833000~20000 0]
2019-07-18 14:51:53.971165 7fffbf7fe700 20 rbd-nbd: writer_entry: got: [3400000000000000 READ 21b38833000~20000 0]
2019-07-18 14:51:53.973706 7fffbffff700 20 rbd-nbd: [3600000000000000 READ 21b38853000~20000 0]: start
2019-07-18 14:51:53.973754 7fffbffff700 20 rbd-nbd: reader_entry: waiting for nbd request
2019-07-18 14:52:54.148726 7fffbffff700 -1 rbd-nbd: failed to read nbd request header: (33) Numerical argument out of domain
2019-07-18 14:52:54.148950 7ffff7fe3000 10 rbd-nbd: stop: terminating
2019-07-18 14:52:54.150668 7fffbf7fe700 -1 rbd-nbd: [3400000000000000 READ 21b38833000~20000 0]: failed to write replay data: (32) Broken pipe
2019-07-18 14:52:54.185349 7fffcf7fe700 20 rbd-nbd: aio_callback: [3600000000000000 READ 21b38853000~20000 0]
2019-07-18 14:52:55.177928 7fffcf7fe700 20 rbd-nbd: aio_callback: [3500000000000000 FLUSH 0~0 0]

As you can see at 14:51:53 a flush request was received, which proceeded at 14:52:55 (i.e. just a bit more than 1 minute). It triggered the 60 sec timeout at 14:52:54 (observed as "failed to read nbd request header: (33) Numerical argument out of domain" error).

It does not look like any issue with rbd-nbd (librbd), but just it did not have enough time to proceed the flush request, either because the cluster was slow or because it was heavy in your case due to rather large cache.

I would suggest to either increase timeout or decrease the rbd cache.

Thank you for the comment, i will tried out smaller rbd-cache sizes now.

I just enabled rbd cache by configuration and used the default memory settings (just "rbd cache = true" and remapping - nothing else).
At first that looks promising, the test runs for 30 minutes without a crash and a single stream iops rate of 200IOPS ("find /srv_ec type f -name "*.sql" -exec gzip -v {} \;") Then it crashed again with the same messages :(

I really think there is something wrong with rbd-nbd or the kernel.

Andditionally i am wondering about:
- why is there a heavy loaded krbd volume on the same system without any crash (30-60% iowait, mixed read/write load) for many months (lifetime)?
- why is the nbd device/mapping always gone and needs to be remapped to get it working when the crash appears?
(from my point of view: if this problem is cased by xfs filesystem code, the nbd device should still work with a xfs problem)
- if this problem is really caused by cache configuration (from my current point of view this is not the case): is the rbd-nbd so fragile a improper rbd cache size setting leads can lead to crashes of the device?

- i disabled rbd cache with "rbd cache = false"
- unmounted and unmapped the image
- mapped and mounted the image
- re-executed my test

find /srv_ec type f -name "*.sql" -exec gzip -v {} \;

It took several hours, but at the end i have the same error situation.

So in the attached log, after the flush was requested, I see many write ops (for dirty cache objects) sent to different osds, like this one:

2019-07-18 14:51:53.961783 7fffcf7fe700  1 -- 10.23.27.200:0/3920476044 --> 10.23.27.150:6814/2366227 -- osd_op(unknown.0.0:1816 36.12s0 36:489d4b84:::rbd_data.34.6c73776b8b4567.00000000000416b7:head [writefull 0~4194304] snapc a8=[a8,a4,a0] ondisk+write+known_if_redirected e256219) v8 -- 0x7fffc8181b90 con 0

2019-07-18 14:52:54.162191 7fffe913b700  1 -- 10.23.27.200:0/3920476044 <== osd.17 10.23.27.151:6806/2322641 63 ==== watch-notify(disconnect (3) cookie 140736414969824 notify 0 ret 0) v3 ==== 42+0+0 (1115836510 0 0) 0x7fffe0a2da30 con 0x7fffc00054d0
2019-07-18 14:52:54.162411 7fffcffff700 -1 librbd::ImageWatcher: 0x7fffc0001010 image watch failed: 140736414969824, (107) Transport endpoint is not connected

Right now I don't see what could be wrong with the librbd (nbd) layer. To me it looks like the osds were just overloaded with requests. Or may be it is network related? It looks a little strange (if it is not a coincidence) that it "unfreezed" after the "watch notify disconnect".

Do the osd report about slow requests at the time when the error occurs? If they do, could you please provide details (e.g. `ceph daemon osd.X dump_historic_ops`)?

As described i repeated my test with a disabled rbd cache.
This leaded to a delay but also same reproduction of the problem.

Our ceph cluster network consists of 10G SFP+ equipment (juniper ex4600) and the virtual machines are connected by a 4*1GBIT connection (juniper ex4300).
All network interfaces of the hypervisor are part of a bonding interface, network load is distributed equally and no network errors are visible on the deeply monitored network and hypervisor equipment.

From my point of view i suppose there is a rbd-nbd, librbd or nbd.ko problem because:
A much more loaded krbd interface (99% utilization, according to "iostat -d -x 120) which is also used on that linux system, runs for months without a problem.

Can you rename the issue to "reproducible rbd-nbd crashes" to help the search engines? :-)

I installed kernel 4.4.0-154.181 (from ubuntu package sources) and performed the crash reproduction because by xenserver runs that release without any problems for months now. The problem also re-appeared with that kernel release.

A bunch of 10 gunzip processes throwed 1600 write and 330 read IOPS against the cluster/the rbd_ec volume with a transfer rate of 290MB/sec for 10 Minutes.
After that the same problem re-appeared.

What should we do now?

Testing with a 10.2.5 librbd/rbd-nbd ist currently not that easy for me, because the ceph apt source does not contain that version.
Do you know a package source?

Marc Schöchlin wrote:

What should we do now?

It seems you ignored my question if ceph reported about slow ops when the issue was observed? As the first step I would like to make sure it is not server side issue. If it is not then it looks like some sort of contention or throttling on the client (rbd-nbd) side. In this case if you could rerun your initial test but with more debugging enabled ("--debug-rbd=20 --debug-ms=5 --debug-objecter=20") it will produce much larger output but it might give some clue.

Also, it would be nice to see perf stats from the rbd-nbd admin socket:

ceph --admin-daemon /path/to/rbd-nbd/client.admin.asok perf dump

Oh sorry, i missed that question for slow requests.
No, we definitely do not have any slow ops when this problem occurs - i checked this multiple times....

From my current point of view our ceph system is currently healthy.
The health log/the dashboard does not output information which leads to problems.
The only thing which is logged are sporadic slow requests while our snapshot creation/deletion process is in progress.
A few months ago, we had a higher amount of slow requests, but after upgrading to 12.2.10 the amount decreased to 1-5 slow request logmessages per day.

I will collect the requested debug data, this night or tomorrow in the morning.

I just read some additional information from the user mailing list about your setup, which I missed before.

So, the setup where the problem is not observed:

our virtual machines of our xen environments completly run on rbd-nbd devices. Every host runs dozends of rbd-nbd maps which are visible as xen disks in the virtual systems.

The setup where the problem is observed.

the problematic rbd-nbd runs on a virtual system which only utilizes one single nbd and one single krbd device.

The fact that you are running `rbd-nbd` inside a VM may be more important than rbd-nbd (or kernel) version. In the xen environment the rbd-nbd is using the host network stack, while on the VM setup it is using a vitrualized network stack, which is not so performant and (at least in the past) known for its issues. So I would check if it is not the case here.

Another thing to consider is that in the xen setup, io requests go through the virt io stack before reaching the rbd-nbd. They might be throttled/queued on this layer before reaching the rbd-nbd, so rbd-nbd is not overloaded with so much requests as it in the VM setup case, where the io requests go directly to the rbd-nbd.

Sorry for the delay, i was a bit ill at the weekend :-)

As described i run a krbd device and(!) a rbd-nbd device in the same virtual machine: The krbd device runs without any problem for months now, the rbd-nbd device can be crashed in reproducible way. The fact that rbd-nbd crashes in the same way with a old and up2date kernel, let me imagine that there is a problem with rbd-nbd or librbd.

As requested i reproduced the problem with "ceph --admin-daemon /path/to/rbd-nbd/client.admin.asok perf dump" invocations and the requested debug/loglevel.

Shell 1:

$ rmmod nbd
$ rbd-nbd --debug-rbd=20 --debug-ms=5 --debug-objecter=20 --id archiv map rbd_hdd/archiv-001-srv_ec --device /dev/nbd0
/dev/nbd0
$ nbd_set_ioctl /dev/nbd0 120
$ mount /dev/nbd0 /srv_ec
$ mount |grep /srv_ec
/dev/nbd0 on /srv_ec type xfs (rw,relatime,attr2,inode64,noquota)
$ while true; do date; ceph --admin-daemon /var/run/ceph/ceph-client.archiv.asok perf dump > /var/log/ceph/perf/perfdump-`date --date="today" "+%Y-%m-%d_%H-%M-%S"`; sleep 5; done

Shell 2:

$ dmesg -c
$ find /srv_ec -name "*.sql" -exec gzip {} \;
$ find /srv/ec -name "*.sql" -print0 |xargs -0 -n 2 -P 10 gzip -v
...
gzip: ./forums_current/redacted1.sql: Input/output error
gzip: ./forums_current/redacted2.sql: Input/output error
gzip: 
gzip: ./forums_current/redacted3.sql: Input/output error

$ dmesg
$ dmesg -T > dmesg-crash

Unfortunately the logfiles are too big for uploading to the ceph tracker :-)
Therefore i uploaded them to my own site.

URI: https://www.256bit.org/nextcloud/index.php/s/nzkHGxzXmrXxzpj
Password: AiT7gah;

• File 1: "test-with-timeout.zip" the problem produced by the procedure listed above (see dmesg output, problem started at Mon Jul 29 21:57:16 2019)
• File 2: "test-without-timeout.zip" almost the same procedure, but without any timeout settings

I have no idea about the cause but here are some observation from the log attached.

For "with timeout" case, there is exactly 2 minute gap (between 21:55:21 and 21:57:21) without any entries in the log:

...
2019-07-29 21:55:21.385551 7fffcf7fe700 20 librbd::BlockGuard: 0x7fffc80f1d10 detain: block_start=607907, block_end=607908, free_slots=32
2019-07-29 21:55:21.385553 7fffcf7fe700 20 librbd::ObjectMap: 0x7fffc80dcd40 detained_aio_update: in-flight update cell: 0x7fffc8256928
2019-07-29 21:55:21.385555 7fffcf7fe700 20 librbd::ManagedLock: 0x7fffc0060470 is_lock_owner=1
2019-07-29 21:55:21.385557 7fffcf7fe700 20 librbd::ObjectMap: 0x7fffc80dcd40 aio_update: start=607907, end=607908, ->1
2019-07-29 21:55:21.385560 7fffcf7fe700 20 librbd::object_map::UpdateRequest: 0x7fffc8171730 update_object_map: ictx=0x555555950e20, oid=rbd_object_map.6c73776b8b4567, [607907,607908) = ->1
2019-07-29 21:55:21.385574 7fffcf7fe700 10 client.24411159.objecter _op_submit op 0x7fffc8357270
2019-07-29 21:55:21.385576 7fffcf7fe700 20 client.24411159.objecter _calc_target epoch 263014 base rbd_object_map.6c73776b8b4567 @34 precalc_pgid 0 pgid 0.0 is_write
2019-07-29 21:57:21.784562 7fffe893a700  5 -- 10.23.27.200:0/1915353349 >> 10.23.27.153:6789/0 conn(0x55555594bdc0 :-1 s=STATE_OPEN_MESSAGE_READ_FOOTER_AND_DISPATCH pgs=1066715 cs=1 l=1). rx mon.0 seq 206 0x7fff988e1c80 osd_map(263015..263015 src has 262285..263015) v3
2019-07-29 21:57:21.785111 7fffbf7fe700 -1 rbd-nbd: [4500000000000000 READ 24043755000~20000 0]: failed to write replay data: (32) Broken pipe
2019-07-29 21:57:21.786462 7fffe37fe700  1 -- 10.23.27.200:0/1915353349 <== mon.0 10.23.27.153:6789/0 206 ==== osd_map(263015..263015 src has 262285..263015) v3 ==== 3981+0+0 (1660450611 0 0) 0x7fff988e1c80 con 0x55555594bdc0
2019-07-29 21:57:21.786487 7fffe37fe700 10 client.24411159.objecter ms_dispatch 0x5555557c66b0 osd_map(263015..263015 src has 262285..263015) v3
2019-07-29 21:57:21.787677 7fffe913b700  5 -- 10.23.27.200:0/1915353349 >> 10.23.27.151:6818/2322735 conn(0x7fffc810ce30 :-1 s=STATE_OPEN_MESSAGE_READ_FOOTER_AND_DISPATCH pgs=799246 cs=1 l=1). rx osd.30 seq 2997 0x7fff9ca940f0 osd_op_reply(154170 rbd_object_map.6c73776b8b4567 [call,call] v263014'3161446 uv3161446 ondisk = 0) v8
2019-07-29 21:57:21.787694 7fffe913b700  1 -- 10.23.27.200:0/1915353349 <== osd.30 10.23.27.151:6818/2322735 2997 ==== osd_op_reply(154170 rbd_object_map.6c73776b8b4567 [call,call] v263014'3161446 uv3161446 ondisk = 0) v8 ==== 215+0+0 (3739644802 0 0) 0x7fff9ca940f0 con 0x7fffc810ce30
2019-07-29 21:57:21.787702 7fffe913b700 10 client.24411159.objecter ms_dispatch 0x5555557c66b0 osd_op_reply(154170 rbd_object_map.6c73776b8b4567 [call,call] v263014'3161446 uv3161446 ondisk = 0) v8
2019-07-29 21:57:21.787706 7fffe913b700 10 client.24411159.objecter in handle_osd_op_reply
2019-07-29 21:57:21.795963 7fffe993c700  5 -- 10.23.27.200:0/1915353349 >> 10.23.27.150:6804/2366065 conn(0x7fffc81430d0 :-1 s=STATE_OPEN_MESSAGE_READ_FOOTER_AND_DISPATCH pgs=1054476 cs=1 l=1). rx osd.21 seq 7433 0x7fffddb47010 osd_map(263015..263026 src has 262285..263026) v3
...

Note, it differs a little from the case reported earlier, as in that log there was still some activity on rados (messanger) layer recorded in that period.

In the "without timeout case" I looks like it worked well by exactly '13:00:00' and since then no nbd requests were recorded, still there were some activity on objecter/messanger layer, related to the watcher. Is that the moment when the test got stuck? Otherwise it just looks like there were no more requests to rbd-nbd since 13:00.

Hello Jason ,

it seems that there is something wrong in the rbd-nbd implementation.
(added this information also at https://tracker.ceph.com/issues/40822)

The problem not seems to be related to kernel releases, filesystem types or the ceph and network setup.
Release 12.2.5 seems to work properly, and at least releases >= 12.2.10 seems to have the described problem.

This night a 18 hour testrun with the following procedure was successful:

#!/bin/bash
set -x
while true; do
   date
   find /srv_ec -type f -name "*.MYD" -print0 |head -n 50|xargs -0 -P 10 -n 2 gzip -v
   date
   find /srv_ec -type f -name "*.MYD.gz" -print0 |head -n 50|xargs -0 -P 10 -n 2 gunzip -v
done

Overview of my tests:

• SUCCESSFUL: kernel 4.15, ceph 12.2.5, 1TB ec-volume, ext4 file system, 120s device timeout
  => 18 hour testrun was successful, no dmesg output
• FAILED: kernel 4.4, ceph 12.2.11, 2TB ec-volume, xfs file system, 120s device timeout
  => failed after < 1 hour, rbd-nbd map/device is gone, mount throws io errors, map/mount can be re-created without reboot
  => parallel krbd device usage with 99% io usage worked without a problem while running the test
• FAILED: kernel 4.15, ceph 12.2.11, 2TB ec-volume, xfs file system, 120s device timeout
  => failed after < 1 hour, rbd-nbd map/device is gone, mount throws io errors, map/mount can be re-created
  => parallel krbd device usage with 99% io usage worked without a problem while running the test
• FAILED: kernel 4.4, ceph 12.2.11, 2TB ec-volume, xfs file system, no timeout
  => failed after < 10 minutes
  => system runs in a high system load, system is almost unusable, unable to shutdown the system, hard reset of vm necessary, manual exclusive lock removal is necessary before remapping the device
• FAILED: kernel 4.4, ceph 12.2.11, 2TB 3-replica-volume, xfs file system, 120s device timeout
  => failed after < 1 hour, rbd-nbd map/device is gone, mount throws io errors, map/mount can be re-created

All device timeouts were set separately set by the nbd_set_ioctl tool because luminous rbd-nbd does not provide the possibility to define timeouts.

Whats next? Is i a good idea to do a binary search between 12.2.12 and 12.2.5?

From my point of view (without in depth-knowledge of rbd-nbd/librbd) my assumption is that this problem might be caused by rbd-nbd code and not by librbd.
The probability that a bug like this survives uncovered in librbd for such a long time seems to be low for me :-)

Regards
Marc

Due to the absence of a coworker i almost had no capacity to execute deeper tests with this problem.
But i can say that in reproduced the problem also with release 12.2.12.

The new (updated) list:

• SUCCESSFUL: kernel 4.15, ceph 12.2.5, 1TB ec-volume, ext4 file system, 120s device timeout
  -> 18 hour testrun was successful, no dmesg output
• FAILED: kernel 4.4, ceph 12.2.11, 2TB ec-volume, xfs file system, 120s device timeout
  -> failed after < 1 hour, rbd-nbd map/device is gone, mount throws io errors, map/mount can be re-created without reboot
  -> parallel krbd device usage with 99% io usage worked without a problem while running the test
• FAILED: kernel 4.15, ceph 12.2.11, 2TB ec-volume, xfs file system, 120s device timeout
  -> failed after < 1 hour, rbd-nbd map/device is gone, mount throws io errors, map/mount can be re-created
  -> parallel krbd device usage with 99% io usage worked without a problem while running the test
• FAILED: kernel 4.4, ceph 12.2.11, 2TB ec-volume, xfs file system, no timeout
  -> failed after < 10 minutes
  -> system runs in a high system load, system is almost unusable, unable to shutdown the system, hard reset of vm necessary, manual exclusive lock removal is necessary before remapping the device
• FAILED: kernel 4.4, ceph 12.2.11, 2TB 3-replica-volume, xfs file system, 120s device timeout
  -> failed after < 1 hour, rbd-nbd map/device is gone, mount throws io errors, map/mount can be re-created
• FAILED: kernel 5.0, ceph 12.2.12, 2TB ec-volume, ext4 file system, 120s device timeout
  -> failed after < 1 hour, rbd-nbd map/device is gone, mount throws io errors, map/mount can be re-created

There is something new compared to yesterday.....three days ago i downgraded a production system to client version 12.2.5.

This night also this machine crashed. So it seems that rbd-nbd is broken in general also with release 12.2.5 and potentially before.

The new (updated) list:

• FAILED: kernel 4.15, ceph 12.2.5, 2TB ec-volume, ext4 file system, 120s device timeout
  -> crashed in production while snapshot trimming is running on that pool
• FAILED: kernel 4.4, ceph 12.2.11, 2TB ec-volume, xfs file system, 120s device timeout
  -> failed after < 1 hour, rbd-nbd map/device is gone, mount throws io errors, map/mount can be re-created without reboot
  -> parallel krbd device usage with 99% io usage worked without a problem while running the test
• FAILED: kernel 4.15, ceph 12.2.11, 2TB ec-volume, xfs file system, 120s device timeout
  -> failed after < 1 hour, rbd-nbd map/device is gone, mount throws io errors, map/mount can be re-created
  -> parallel krbd device usage with 99% io usage worked without a problem while running the test
• FAILED: kernel 4.4, ceph 12.2.11, 2TB ec-volume, xfs file system, no timeout
  -> failed after < 10 minutes
  -> system runs in a high system load, system is almost unusable, unable to shutdown the system, hard reset of vm necessary, manual exclusive lock removal is necessary before remapping the device
• FAILED: kernel 4.4, ceph 12.2.11, 2TB 3-replica-volume, xfs file system, 120s device timeout
  -> failed after < 1 hour, rbd-nbd map/device is gone, mount throws io errors, map/mount can be re-created
• FAILED: kernel 5.0, ceph 12.2.12, 2TB ec-volume, ext4 file system, 120s device timeout
  -> failed after < 1 hour, rbd-nbd map/device is gone, mount throws io errors, map/mount can be re-created

Charateristic of the crashed vm machine:

• Ubuntu 18.04, with kernel 4.15, Ceph Client 12.2.5
• Services: NFS kernel Server, nothing else
• Crash behavior
  • daily Task for snapshot creation/deletion started at 19:00
  • a daily database backup started at 19:00, this created
  • 120 IOPS write, and 1 IOPS read
  • 22K/sectors per second write, 0 sectors/per second
  • 97 MBIT inbound and 97 MBIT outbound network usage (nfs server, inbound=nfs, outbound=rbd)
  • we had slow requests at the time of the crash
  • rbd-nbd process terminated 25min later without segfault
  • the nfs usage created a 5 min load of 10 from start, 5K context switches/sec
  • memory usage (kernel+userspace) was 10% of the system
  • no swap usage
  • ceph.conf
    

        [client]
        rbd cache = true
        rbd cache size = 67108864
        rbd cache max dirty = 33554432
        rbd cache target dirty = 25165824
        rbd cache max dirty age = 3
        rbd readahead max bytes = 4194304
        admin socket = /var/run/ceph/$cluster-$type.$id.$pid.$cctid.asok
        

  • 4 CPUs
  • 6 GB RAM
  • Non default Sysctl Settings
    

        vm.swappiness = 1
        fs.aio-max-nr = 262144
        fs.file-max = 1000000
        kernel.pid_max = 4194303
        vm.zone_reclaim_mode = 0
        kernel.randomize_va_space = 0
        kernel.panic = 0
        kernel.panic_on_oops = 0
        

I'm now at vacation until 8. October 2019.
My coworker will have a look at this issue i case that you have additional questions.

Any updates here?

I think the severity of this problem (currently "minor") is not suitable to the consequences of this problem.

This reproducible problem (as describe d on the list by Mike) can cause:

• random service outage
• data corruption
• long recovery procedures on huge filesystems

Is it adequate to increase the severity to major critical?

@Marc: in all honesty, changing the priority / severity won't affect the timeline. Mike is already looking into the issue and it appears there is a bug in XFS (but still more issues w/ memory pressure and rbd-nbd). Perhaps retest using ext4 or another filesystem in the meantime.

The kernel side fix for this issue has been posted here

https://lkml.org/lkml/2019/9/9/549

The ceph side just has the rbd-nbd reader/writer and its msgr-worker threads set that setting along with mlock (not really needed unless we are doing rbd-nbd swap, but it simplifies the IO path) and oom adjust score to prevent the oom killer from killing us when some other process/driver needs to free memory by writing to us.

Will post a link to the ceph PR when the kernel interface is approved, because I am guessing the kernel interface will change a lot.

As described in my last mail on the mailinglist i converted the filesystem to ext4, set "sysctl vm.dirty_background_ratio=0" and I put the regular workload on the filesystem (used as a NFS mount).
That seems so to prevent crashes for a entire week now (before this, the nbd device crashed after hours/~one day).

XFS on top of nbd devices really seems to add additional instability situations.

The current workaround causes very high cpu load (40-50 on a 4 cpu virtual system) and up to ~95% iowait if a single client puts a 20GB File on that volume.

What is your current state in correcting this problem?
Can we support you in testing the by running tests with custom kernel- or rbd-nbd builds?

Regards
Marc

From my perspective rbd-nbd is really broken for months now. Or is this just a edge-case which is only relevant for a very low number of users?