Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
overflow of disk.role db field #1709
Thanks to forum members wellman and scanlom for reporting and confirming this issue. In the linked forum post there is evidence of a Disk.model field being insufficiently long:
Given the only field in our Disk model that is 256 characters long is the Disk.role:
it is the most obvious candidate.
Currently the suspicion is that we have a combination of many partitions on a device with a long by-id name: resulting in an overly lengthy 'partitions' role value.
Linking to the forum thread for context:
From the above referenced forum thread we have confirmation of 8 partitions on a single drive where upon removal of the partitions normal function returned. Thanks to scanlom for confirming this.
Results in a mock-up role field including just the obligatory 'partitions' role of:
just including the partitions role gives 408 characters: almost double the current 256 char limit.
I have recorded a 50 char name (including partition) ie:
So per disk we have eg:
= 18 + part-count*(52+10)
As such I propose that we quadrupal the length of this field to 1024 characters as although directly after install we may see an 8 partition long file name device which would give around 514 chars (so double is not good) but it might be that a user would then wish to add a redirect role:
'"redirect": "usb-SanDisk_Extreme_AA011219150433452149-0:0-part3", ' = 66 characters more.
Hence the suggestion that we should be good at 1024 characters.
This would mean we are good up to 15 partitions plus a redirect role given the above assumptions on dev name length (50+"") and ext4 = 1020 chars. This is an unlikely configuration and is likely to shortly there after be subject to a complete wipe but would at least facilitate such external drive use were it to be required. Although that may very well require an additional (as yet not implemented) role.
Our current default of 256 chars and the given long dev name is good for only 2 partitions with and 3 partitions without a redirect role. This is clearly insufficient and an over-site on my part in pr #1622 and specifically commit:
We have however had 2 report in > 5 months so this is not a common overflow but would be very nice to extend given the above exposition.
User work around until we extend this model/field is to wipe the problematic drives (via command line) and refresh the page. There-by removing the cause of the overflow. It is unlikely in normal Rockstor use (given no partitions are the preferred configuration) that this role will overflow there after.
Another as yet theoretical instance of db role field overflow would be that of an "encrypt my data" install which results in an encrypted system disk. Hence an open LUKS volume which is also partitioned. This arrangement is proposed as a supported configuration (for system disk only) in the currently open #550 issue to account for default encrypted installs.
An example of the resulting role field in this case for the system disk on the longest so far observed device name would be:
Resulting in a 206 character role field. Leaving 256-206 = 50 characters remaining. However a non standard partition arrangement or custom keyfile arrangement could result in a disk.role field overflow.
A more likely scenario for disk.role overflow is that of encountering an existing partitioned Open LUKS Volume (not supported) which would immediately exceed the 256 character limit. So although this is not supported it is not an unlikely encounter on a fresh install.
In the above linked issue (now closed as a duplicate) #1715 GitHub user @tomvancutsem also experienced this db field overflow on prior use (partitioned) disks. As per the originally referenced forum post, wiping these prior use partitions resolved the issue. Noting here as confirmation of the current workaround; and thank to @tomvancutsem for their confirmation and feedback.
added a commit
May 23, 2017
referenced this issue
May 23, 2017
Please also update the following forum thread and forum user HBDK with this issues resolution:
Thanks to forum member HBDK in the following forum thread for initially reporting and then assisting with diagnosing an additional trigger for this db field overload. And for supplying the now longest so far seen device name of 51 character. One char better than the previously referenced 'worst case' device:
With mdraid system disks installs such as in:
The resulting role field would then be (using HBDK's info):
representing a 275 char requirement.
Referenced forum thread:
@schakrava Given that we have now had a few reports of breakage due to this field length overflow I suggest that the associated pr be considered for merge at the earliest convenience. Especially given the additional pressure that #1716 places on this field. It is still the case that all reports are semi-exceptional, ie many partitions on prior use data drives but the mdraid install just detailed above is a far more difficult problem to work around on client installs.