I’m just starting to play with Rockstor, and I wanted to change the mount options of the rockstor_rockstor pool (the one created by default during install process).
Given that my rockstor system is installed on an SSD drive, I would like to add the “ssd” mount option for this pool.
But here is the error it pops up me when I try to enter “ssd” in the form :
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/pool.py", line 351, in put
'as it contains the operating system.' % pid)
TypeError: %d format: a number is required, not unicode
Reading the error, I would say it’s due to a Python coding error not related to my “ssd” input… But it might also be me who did some mistake during the config…
Maybe someone who has a better knowing of rockstor could help me with that ?
It is as you suspect a programmatic error but is a little more involved than it first appears. Regardless we have the following issue to address the formatting of the message itself:
I plan to address this shortly so will update this thread accordingly. The slightly more involved element of your report is that we don’t actually support rockstor_rockstor (the system pool) mount options. Or at least we haven’t intended to support this. If you look at the pool page (Storage - Pools) you will see that there are no Compression or Extra mount options visible (as intended) so as it goes you have brought to light an anomaly / inconsistency where in the same pools details page there is an option to change these options. Although, as you report, it results in a backend ‘blocking’ message to that effect ie the message is supposed to say “Edit operations are not allowed on this Pool(pool-name) as it contains the operating system.”. But as it’s currently not actually supported just yet I have opened the following issue that I should also be able to address shortly:
So thanks for reporting this and as per your ssd mount option the ssd flag itself is due to be ‘downgraded’ in upstream btrfs as it was found to be counter productive and the native function of btrfs’s copy on write is actually fairly ssd friendly. So I wouldn’t worry about this too much. I.e take a look at the following archive of a linux-btrfs mailing list:
and later in that same thread there are some nice btrfs-heatmap references as Hans was making his point re the indicated ssd mount option proposed changes:
Finally managed to tend to at least the second indicated issue in this thread. As from stable channel release 3.9.2-17 the following issue has now been addressed:
The other indicated issue I referenced earlier in this thread has also been addressed but the code is not yet released as it has turned into a system wide test enhancement as we had several issues of that type so I set about revamping our unit testing which has proven to be a little more involved that I had first expected.