phillxnet
commented
1 year ago @ubenmackin Hello again. And thanks for the detailed report.
Re:
What I am left wondering is if somehow the code for the root disk lookup is parsing the root disk string,
We have a little bit of a legacy arrangement with the root pool, it's rather special-cased here and there as it was coded before we had btrfs in partition capability, and so there is definitely work to be done in transitioning the ROOT pool code over to our data pool arrangements. This is work that has waited too long unfortunately.
Could you confirm if you are using a data drive as a system drive also? I.e. the expectation, and the only arrangement understood by the Web-UI is that the two cannot be mixed. I.e. ROOT must be a dedicated device. What leads me to this question is:
Not only is the pool listed wrong, but so is the Capacity. This is a 10 TB disk, but it is being show on the disk page as only 109 GB, the size of my ROOT disk.
Part of the special case-ness of the system pool (btrfs in partition) is that we only show the "/" mount point size, and not the host drive size. Not normally that far out for a dedicated device. But your reported sizes are way out.
Could you paste the output of the following command for us here if you can, note that serial numbers will be included, and it's important not to obscure them as that is our canonical guide on drive identification (but you could modify them consistently if that is something you would rather now share):
https://forum.rockstor.com/t/device-management-in-rockstor/1768
Ideally what we need here is a local reproducer, to help with that could you paste the output of the following commands:
lsblk -P -o NAME,MODEL,SERIAL,SIZE,TRAN,VENDOR,HCTL,TYPE,FSTYPE,LABEL,UUIDWhich is used in this key low level bit of code: https://github.com/rockstor/rockstor-core/blob/23a8df915857269f8662e8cf16a5d485baa34f87/src/rockstor/system/osi.py#L267-L280
and
ls -la /dev/disk/by-id/as we use by-id names extensively - but serial is king.
The above osi.py link is where we end up mixing our old and new btrfs in partition identification mechanism. Unfortunatly the ROOT pool (system drive) code is, as stated, full of special cases that really need to be cleaned up. But we also have to honour continuity of function: however we have quite a few tests to help with this, see: https://github.com/rockstor/rockstor-core/blob/testing/src/rockstor/system/tests/test_osi.py
Curiously enough we have an existing test involving 36 disks that was created a few years ago when we had some high disk number issues: https://github.com/rockstor/rockstor-core/blob/23a8df915857269f8662e8cf16a5d485baa34f87/src/rockstor/system/tests/test_osi.py#L602-L616
and another that was for 27+ disk counts: https://github.com/rockstor/rockstor-core/blob/23a8df915857269f8662e8cf16a5d485baa34f87/src/rockstor/system/tests/test_osi.py#L916-L931
But for the time being lets see if we can create a local test to reproduce what you have there, again assuming:
devid 1 size 109.72GiB used 37.60GiB path /dev/sdag4is not also used in a data pool somewhere. If it is then your setup is definitely out-of-scope for what we can currently handle: the system disk can't also be part of any data pool. Which is a pain especially with big drives. But this limitation will continue to be the case as we like to enforce separation of concerns. So the answer is usually to use a smaller dedicated device for the system disk, or absorb the 'space waste' of course.
Thanks again for the report, all good for rooting out issues in this low level stuff. However we have not had to touch any of this for a few years now. But I've been itching to re-do the system drive btrfs-in-partition to bring it in line with the far newer code of that for data drives. Our current testing phase is concerned primarily with addressing technical dept, but that is now more than half way thought so hopefully we can chip away at your observed failing as we go along. I'll probably thow out the mdraid special case for system pool also as that further complicates things and we should soon benefit from grub improvements re btrfs and boot devices.
Hope that helps, at least with some context. And again the report is much appreciated. Take a look at those tests and see if you can create one that reproduces what you have there; if so then that would be a major step towards us seeing exactly what is going wrong here: again assuming the system drive plays no part in any data pool.
ubenmackin
Hooverdan96
Hello again!
I was going to make a forum post, but for some reason was having issues loading the forum.
At any rate, I have a strange issue. My system has a lot of disks (currently 35) spread across a number of pools. This has caused my drive disk labels to cycle from sda to sdz, and then to sdaa, sdab, sdac, etc.
Recently I noticed that my ROOT pool, which consists of a single disk was showing with two disks in the Pool viewer. Also, when looking at the Disks page, the ROOT pool shows with two disks, which is incorrect.
Not only is the pool listed wrong, but so is the Capacity. This is a 10 TB disk, but it is being show on the disk page as only 109 GB, the size of my ROOT disk.
Logging into the shell, and doing a
btrfs fi showShows everything correctly. So it seems to be just a display issue in Rockstor.
I am guessing the issue is due to the drive lettering. Here is my ROOT pool:
And here is the pool that is having a disk mislabeled:
devid 2 from JBOD is the disk showing incorrectly Rockstor.
What I am left wondering is if somehow the code for the root disk lookup is parsing the root disk string, and assuming only three characters? Or maybe there is a regex someplace, and it is finding sda in sdag, and thus labeling it as a ROOT drive when it is not?
I tried digging through btrfs.py and osi.py, and found a couple of places where some parsing is happening from /proc/mounts or lsblk, but I didn't see anything that stood out that might be causing this. Figured I'd post this here, in case anyone else has come across this.