Hi,
There are strange bug when I tried to map excessive amounts of block
devices inside the pool, like following
for vol in $(rbd ls); do rbd map $vol; [some-microsleep]; [some
operation or nothing, I have stubbed guestfs mount here] ;
[some-microsleep]; unmap /dev/rbd/rbd/$vol ; [some-microslee
On 05/15/2012 06:49 AM, Andrey Korolyov wrote:
Hi,
There are strange bug when I tried to map excessive amounts of block
devices inside the pool, like following
for vol in $(rbd ls); do rbd map $vol; [some-microsleep]; [some
operation or nothing, I have stubbed guestfs mount here] ;
[some-micros
On 05/15/2012 04:49 AM, Andrey Korolyov wrote:
Hi,
There are strange bug when I tried to map excessive amounts of block
devices inside the pool, like following
for vol in $(rbd ls); do rbd map $vol; [some-microsleep]; [some
operation or nothing, I have stubbed guestfs mount here] ;
[some-micros
>This is most likely due to a recently-fixed problem.
>The fix is found in this commit, although there were
>other changes that led up to it:
> 32eec68d2f rbd: don't drop the rbd_id too early
>It is present starting in Linux kernel 3.3; it appears
>you are running 2.6?
Nope, it`s just Debian k
Hi,
Newer kernel rbd driver throws a quite strange messages on map|unmap,
comparing to 3.2 branch:
rbd map 'path' # device appears as /dev/rbd1 instead of rbd0, then
rbd unmap /dev/rbd1 # causes following trace, w/ vanilla 3.4.0 from kernel.org:
[ 99.700802] BUG: scheduling while atomic: rbd/3
That looks like a bug that isn't familiar to Josh or I. Can you create a report
in the tracker and provide as much debug info as you can come up with? :)
On Friday, May 25, 2012 at 3:15 AM, Andrey Korolyov wrote:
> Hi,
>
> Newer kernel rbd driver throws a quite strange messages on map|unmap,
>
