Error Importing RAID1 Volume Created in Ubuntu (DEADLOCK)

Troubleshooting
1

Hi everyone! I’m trying to import a BTRFS RAID 1 array originally crated in Ubuntu to Rockstor, but I ran into the following error:

Failed to import any pool on this device(23). Error: deadlock detected DETAIL: Process 13198 waits for ShareLock on transaction 3192; blocked by process 13462. Process 13462 waits for ShareLock on transaction 3190; blocked by process 13198. HINT: See server log for query details.

        Traceback (most recent call last):

File “/opt/rockstor/src/rockstor/storageadmin/views/disk.py”, line 699, in _btrfs_disk_import
do.save()
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/base.py”, line 734, in save
force_update=force_update, update_fields=update_fields)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/base.py”, line 762, in save_base
updated = self._save_table(raw, cls, force_insert, force_update, using, update_fields)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/base.py”, line 827, in _save_table
forced_update)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/base.py”, line 877, in _do_update
return filtered._update(values) > 0
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/query.py”, line 580, in _update
return query.get_compiler(self.db).execute_sql(CURSOR)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/sql/compiler.py”, line 1062, in execute_sql
cursor = super(SQLUpdateCompiler, self).execute_sql(result_type)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/models/sql/compiler.py”, line 840, in execute_sql
cursor.execute(sql, params)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/backends/utils.py”, line 64, in execute
return self.cursor.execute(sql, params)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/utils.py”, line 98, in exit
six.reraise(dj_exc_type, dj_exc_value, traceback)
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/db/backends/utils.py”, line 64, in execute
return self.cursor.execute(sql, params)
OperationalError: deadlock detected
DETAIL: Process 13198 waits for ShareLock on transaction 3192; blocked by process 13462.
Process 13462 waits for ShareLock on transaction 3190; blocked by process 13198.
HINT: See server log for query details.

The array has a nickname and should be import-able.

Thanks for your help!

2

@juchong Welcome to the Rockstor community.

Could you first let us know the version of Rockstor you are running? This can be double checked via:

yum info rockstor

as we have a bug when moving from the testing to stable update subscriptions such that the displayed version can be wrong.

And due to development changes / priorities our stable branch is now far ahead of the testing branch.

I mention this as there have been a number of improvements in many areas of the code including the import (from memory) so it’s worth making sure you are on the latest version of code you favour before proceeding. Also note that Rockstor doesn’t recognise all btrfs arrangements but this is most likely to result in subvols not being recognised/exposed in the Web-UI as apposed to a db deadlock. But it could still be the cause, ie the import code causing a db deadlock as it sees an arrangement it’s never been tested with.

Also a paste of the following command output may be useful:

btrfs fi show

And a screen grab of the disks page may also be useful.

By nickname I assume you mean label, and yes Rockstor does require the pool (btrfs vol) to be labelled.

Hope that helps and lets see first if a simple update channel subscription with update sorts your issue.

3

Hi! It looks like I was able to successfully add the btrfs filesystem after I accessed it via the terminal once. For some reason, this triggered Rockstor to detect the filesystem.

4

@juchong Thanks for the update and glad you got it sorted.

Bit of a strange one that, were the drives live plugged? This can lead to a requirement for a ‘btrfs dev scan’ but we try to account for that anyway. Also initial recognition of device fs contents is done via udev / lsblk so maybe an action you took while logged in refreshed that info.

Best to still confirm your installed Rockstor version re the prior indicated bug by the way.

and by:

I assume you mean import.

Well done persevering and hope it goes more smoothly going forward.

5

The drives were not hot-plugged or anything odd like that. I suspect a restart would’ve also taken care of the import. I eventually wiped the array anyway, but maybe this thread will be helpful to someone in the future.