Dne 03. 12. 21 v 15:42 Nikos Tsironis napsal(a):
On 12/2/21 5:41 PM, Zdenek Kabelac wrote:
Dne 01. 12. 21 v 18:07 Nikos Tsironis napsal(a):
Hello,
Under certain conditions, swapping a table, that includes a dm-era
target, with a new table, causes a deadlock.
This happens when a status (STATUSTYPE_INFO) or message IOCTL is blocked
in the suspended dm-era target.
dm-era executes all metadata operations in a worker thread, which stops
processing requests when the target is suspended, and resumes again when
the target is resumed.
So, running 'dmsetup status' or 'dmsetup message' for a suspended dm-era
device blocks, until the device is resumed.
Hi Zdenek,
Thanks for the feedback. There doesn't seem to be any documentation
mentioning that loading the new table should happen before suspend, so
thanks a lot for explaining it.
Unfortunately, this isn't what causes the deadlock. The following
sequence, which loads the table before suspend, also results in a
deadlock:
1. Create device with dm-era target
# dmsetup create eradev --table "0 1048576 era /dev/datavg/erameta
/dev/datavg/eradata 8192"
2. Load new table to device, e.g., to resize the device
# dmsetup load eradev --table "0 2097152 era /dev/datavg/erameta
/dev/datavg/eradata 8192"
3. Suspend the device
# dmsetup suspend eradev
4. Retrieve the status of the device. This blocks for the reasons I
explained in my previous email.
# dmsetup status eradev
Hi
Querying 'status' while the device is suspend is the next issue you need to
fix in your workflow.
Normally 'status' operation may need to flush queued IO operations to get
accurate data.
So you should query states before you start to mess with tables.
If you want to get 'status' without flushing - use: 'dmsetup status --noflush'.
5. Resume the device. This deadlocks for the reasons I explained in my
previous email.
# dmsetup resume eradev
6. The dmesg logs are the same as the ones I included in my previous
email.
I have explained the reasons for the deadlock in my previous email, but
I would be more than happy to discuss them more.
There is no bug - if your only problem is 'stuck' status while you have
devices in suspended state.
You should NOT be doing basically anything while being suspend!!
i.e. imagine you suspend 'swap' device and while you are in suspened state
kernel decides to swap memory pages - so you get instantly frozen here.
For this reason lvm2 while doing 'suspend/resume' sequance preallocates all
memory in front of this operation - does very minimal set of operation between
suspend/resume to minimize also latencies and so on.
Clearly if you suspend just some 'supportive' disk of yours - you likely are
no in danger of blocking your swap - but the 'status --noflush' logic still
applies.
Regards
Zdenek
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
