Lately I’ve been getting error messages like this:
[25/May/2017 05:00:07] ERROR [storageadmin.util:44] exception: value too long for type character varying(256)
Traceback (most recent call last):
File “/opt/rockstor/src/rockstor/rest_framework_custom/generic_view.py”, line 41, in _handle_exception
yield
File “/opt/rockstor/src/rockstor/storageadmin/views/disk.py”, line 320, in post
return self._update_disk_state()
File “/opt/rockstor/eggs/Django-1.8.16-py2.7.egg/django/utils/decorators.py”, line 145, in inner
return func(*args, **kwargs)
File “/opt/rockstor/src/rockstor/storageadmin/views/disk.py”, line 268, in _update_disk_state
dob.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)
DataError: value too long for type character varying(256)
i don’t really know when it started but looking in the logs i can see that the oldest entry in it is the error from the 3rd of may this year.
i hope someone can help me shed some light on this problem and hopefully fix it.
The only trigger for this I’ve seen in the wild so far was related to a good few partitions on an existing device. Can’t know if your cause is this also but could probably tell with the output of:
ls -la /dev/disk/by-id/
Good news is, in an attempt to redeem myself, I have submitted a fix: Please see issue:
Where forum member @wellman in the following thread helped with output from the same above command. That issue also covers some as yet unreported possible causes for the same value overflow.
And the fix is awaiting code review via pull request:
Also see the now closed as duplicate report by Github user tomvancutsem who was able to confirmed that the partitions count was also the cause for his experiencing this error:
Hope that helps.
So short of it is that if my pull request passes muster then a fix should be available shortly in a future update. In the mean time the only work around is to reduce the partition count on the problem drive or drives. Which may not be an option given it can involve data loss. And the output of the above command should indicate the drive that is causing this. ‘As is’ it will block Rockstor’s ability to update drive state which is not good but has only been observed in more unusual partitioning cases so would be good to know if this is also the case in your setup.
@HBDK Thanks for the output, You do have a long device name there, ie the Corsair SSD, with is 51 character, 1 longer than I have as my longest seen so far so thanks. I’ve updated my spreadsheet to indicate failure points as a result. But 3 partitions shouldn’t overflow as the db entry would I think only be 207 characters without a redirect role applied, at least for the partitions role alone. But 4 would.
Could you give the output of:
Yes this has helped and has identified a further over-site on my part.
I have updated the above issue with the proof and the reason I missed this initially and referenced your contribution.
Essentially I had assumed that only 2 of the 3 partitions would be listed and that was my finding on my test mdraid install here; your report led to me looking a little more closely at the db field contents on this test system:
So an ‘mdraid’ role and the associated partitions. Even with your long names there should still not be an overflow of the 256 chars. Anyway I had wrongly attributed the absence of the part2 listing to a type of swap which we ignore however for these mdraid installs all partitions are the rather long fs type of “linux_raid_member” as swap is higher up. On investigation the missing part2 in my test mdraid setup is down to size not type as we also exclude everything that is less than 1G which my test mdraid install swap partition is (SIZE=“954M”). Silly me. I was attempting to use the minimum spec of an 8GB system disk and inadvertently covering up this issue (at least for mdraid system disk installs).
So thanks for reporting: and the explanation of your db field overflow is as a result of the system attempting to store the following:
Which is 275 chars (19 chars over). Hence the breakage.
I am reluctant to provide a ‘hack’ workaround given the pending fix in the referenced pr (which quadruples the max field length to 1024 chars), and the only fairly non invasive one I can think of only saves 17 characters and given your long dev names is just not enough (though it would be if they were only 50 chars long!).
Apologies for the inconvenience and thanks again for assisting with improving things going forward.
My expectation is that once the pending fix is released your system should then function as expected.
@HBDK Great. Also if you set email notifications within Rockstor you should have received an email via default root email being redirected to the notification address for the missing mdraid member. http://rockstor.com/docs/email_setup.html
Just a notification that a fix for the issue you reported in this thread has now been release in testing channel updates version 3.9.0-8.
So you should be able to upgrade (if you are on testing channel updates) and, once you have rebooted there after, or executed “systemctl restart rockstor-pre” to enable the then pending model/db field migration to it’s longer variant, you should be sorted.
Thanks for you patience and helping to route out another trigger for this model/db field overflow issue.
