Ceph » rbd

No progress on this. None expected unless it gets
reprioritized and planned.

I can't relate them but this is involved in at
least some of the code involved:
http://tracker.ceph.com/issues/3858

I don't know what's going on here.

I'm using close to current code--testing branch is currently at:
4c7a08c8 Merge branch 'testing' of github.com:ceph/ceph-client into into linux-3.8-ce

I was able to have a dd command terminate slightly early:

root@plana92:/# dd if=/dev/zero of=/dev/rbd2 bs=1M count=1000
^C934+0 records in
934+0 records out
979369984 bytes (979 MB) copied, 28.1845 s, 34.7 MB/s

root@plana92:/# 

I also noticed, in a separate window, that our old friend
udev (blkid, really) is rearing its head again:

root@plana92:~# ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:03 /sbin/init
    2 ?        S      0:00 [kthreadd]
    . . .
14441 ?        S      0:00 [kworker/0:0]
14476 pts/0    D+     0:00 dd if=/dev/zero of=/dev/rbd2 bs=1M count=1000
14489 ?        D      0:00 /sbin/blkid -o udev -p /dev/rbd2
14490 pts/2    R+     0:00 ps ax
root@plana92:~# 

This is while the dd was underway. I'm think the "dd"
command has finished filling buffers and they have not
been drained to disk yet. And maybe the device has been
closed, and blkid is just launching on that, the last
close.

As a matter of fact, I tried running the dd command under
strace and I do indeed see that the writes are done after
about 2 seconds (including outputing all that info about
the trace) at which point the close begins, and takes
another 40 seconds or so before it comes back.

On other times I can interrupt it, and it takes some time
but it does get interrupted.

root@plana92:/# date; dd if=/dev/zero of=/dev/rbd2 bs=1M count=1000
Fri Feb 22 14:58:34 PST 2013
^Cdate
573+0 records in
573+0 records out
600834048 bytes (601 MB) copied, 27.6617 s, 21.7 MB/s

root@plana92:/# date
Fri Feb 22 14:59:01 PST 2013
root@plana92:/# 

Whatever. Still a problem I guess. Or maybe not a problem
with rbd at all.

One more thing, trying this with smaller buffers seems to
improve responsiveness. I really do think this is not
an rbd issue at all.

root@plana92:/# date
Fri Feb 22 15:04:33 PST 2013
root@plana92:/# date; dd if=/dev/zero of=/dev/rbd2 bs=10K count=100000
Fri Feb 22 15:04:51 PST 2013
^Cdate
973+0 records in
973+0 records out
9963520 bytes (10 MB) copied, 3.43551 s, 2.9 MB/s

root@plana92:/# date
Fri Feb 22 15:04:55 PST 2013
root@plana92:/# 

Here's 1K buffers, even better.

root@plana92:/# date; dd if=/dev/zero of=/dev/rbd2 bs=1K count=1000000
Fri Feb 22 15:05:37 PST 2013
^Cdate
1257+0 records in
1257+0 records out
1287168 bytes (1.3 MB) copied, 3.30894 s, 389 kB/s

root@plana92:/# date
Fri Feb 22 15:05:40 PST 2013
root@plana92:/# date; dd if=/dev/zero of=/dev/rbd2 bs=1K count=1000000
Fri Feb 22 15:05:56 PST 2013
^Cdate
1457+0 records in
1457+0 records out
1491968 bytes (1.5 MB) copied, 3.6796 s, 405 kB/s

root@plana92:/# date
Fri Feb 22 15:06:00 PST 2013
root@plana92:/# 

I think we can probably close or reject this.