I run Rockstor 5.0.8 (Leap 15.5) in a ProxMox VM. I needed more space, so in ProxMox I grew the disk size that’s used for /dev/sdc from 10TB to 20TB. The new disk size is reflected at the kernel level in opensuse:
However it’s not reflected in the Rockstor UI, no matter how often I click the Rescan button. So I can’t expand the btrfs pool to take advantage of the new size.
How do I resolve this?
I swear I thought I had done this successfully before in Rockstor 4.6.3 on tumbleweed, but maybe I’m wrong?
And if a disk is bigger than its pool, should there not be an “expand pool” option in the pools UI?
I created these pools directly on the raw devices using the UI for everything. My understanding was that no partitions are created when doing it this way. There’s no partition table on this disk. It’s just a “whole disk” btrfs volume
You weren’t wrong, that is the correct command to accomplish that. In my case it was btrfs filesystem resize max /mnt2/rockpool
But I’m still not understanding why the UI didn’t see the larger disk, or why it wouldn’t let me expand the volume from there. It seems like the Disks page is only displaying btrfs volumes on the default devid rather than actual disks, which I know isn’t the case because I’ve had specific partitions listed there before that did not have anything to do with btrfs.
And I swear I’ve done exactly this before without issues on 4.6.3
@GoreMaker yes, this is curious on the raw device piece … I don’t have an answer, but I was able to replicate your observation (albeit using VirtualBox and not proxmox) on 4.5.8-0 on Leap15.5 (no kernel backport installed).
Growing a drive from 6GB to 8GB using VBox’s media manager. The disk page should (as you mentioned) show the increased size. But, like in your case, it doesn’t for me either:
(do not remember why the second p option is there, but just to follow what the coding is doing), the output is this:
NAME MODEL SERIAL SIZE TRAN VENDOR HCTL TYPE FSTYPE LABEL UUID
/dev/sda VBOX HARDDIS VBa2572f87-ff8 12G sata ATA 0:0:0:0 disk
├─/dev/sda1 2M part
├─/dev/sda2 64M part vfat EFI 6B75-B8F6
├─/dev/sda3 2G part swap SWAP 47109a0d-29c5-4472-9d1e-a16efe70c2c7
└─/dev/sda4 9.9G part btrfs ROOT d0c1da4b-39d9-418c-a5f0-8077210d7f75
/dev/sdb VBOX HARDDIS VB88af474c-d1e 6G sata ATA 1:0:0:0 disk btrfs rocksalami 9862f48a-d953-4759-8002-d826185c473c
/dev/sdc VBOX HARDDIS VBc83a5941-724 6G sata ATA 2:0:0:0 disk btrfs rocksenf 4094b6a3-efb6-46b2-9408-1777de9c0df5
/dev/sdd VBOX HARDDIS VB94d95720-603 6G sata ATA 3:0:0:0 disk btrfs rocksalami 9862f48a-d953-4759-8002-d826185c473c
/dev/sde VBOX HARDDIS VB3293073a-4cc 6G sata ATA 4:0:0:0 disk btrfs rocksalami 9862f48a-d953-4759-8002-d826185c473c
/dev/sdf VBOX HARDDIS VBd089f450-ffc 8G sata ATA 5:0:0:0 disk btrfs rocksenf 4094b6a3-efb6-46b2-9408-1777de9c0df5
/dev/sr0 VBOX CD-ROM VB2-01700376 1024M ata VBOX 7:0:0:0 rom
and as one can see /dev/sdf shows up as 8GB there.
I suspect, because it’s not a “new” disk, the updates done during this method:
does not update the size of the disk, as it recognizes it as an existing one that’s already on a btrfs filesystem, but I have not analyzed the code here in detail. Both of these function have not been updated really in the last 2 years. If your memory is correct then the only thing I can imagine is that TW provides some different output of the lsblk command that would make Rockstor think it’s actually a new disk (if my assumption above is correct).
In summary, I suspect that the assumption has mostly been that a production Rockstor would most likely run on bare metal and hence a magic growth of a disk size would not usually occur.
@phillxnet, since you’ve delved into this area time and time again, maybe you can shed some more light on this, if you have time.
To your point above, at this time it seems that one doesn’t need to do any partitioning (as you rightly pointed out) but would run (at the command line) a resizing of the btrfs system of the mounted filesystem.
We have a reproducer for this now, and as stated we assume / strongly suggest hardware drives: which simply don’t do this. But we can/should accommodate without too much effort. Nothing has, as you say, changed in this area for some time: due to the focus of our more recent testing phases.
Could you create an issue: given you have a reproducer, siting @GoreMaker as the reporter.
I would not be inclined to tent to this issue in the current testing phase though (we are on RC3 already), or likely want to merge a change this low-down that does not relate to our supported configurations as per recommendations in our:
Our current next stable Milestone does have a simple bug to be addressed: but that pertains to a recommended configuration: real drives.
But our next testing phase (not long now) would be a good one to tend to this. We must have tests at this level of the code though.
The btrfs need to be expanded to fit larger host drives is covered in a tangentially related situation covered in our docs re drive in-situation replacment (via btrfs replace) here:
I.e. the filesystem does not auto-expand when a member increases it’s size: even if that drive has no partitions. When the filesystem was created the available member sizes is set. Changes to those drive sizes are not auto honoured. But one can request, as per that doc entry, that a Pool member be expanded to fit any sub btrfs expansion that may have taken place.
@GoreMaker Another nice find. Thanks. This would be nice to tend to, but any layer between btrfs and the hardware is a reduction of data security; ergo not ideal. However we are moving: bit by bit, to be able to cope with progressively more changing circumstances as we go. But out Web-UI is a little stinted currently re reporting dynamic changes. And we hope to address in more in the next testing phase as we improve/update things more in the Web-UI area. And adding a more dynamic/live nature nature is definitely on the cards. But by take a while as we have to re-architect a few bits and bobs. Report you findings once you have expanded (via cli) the btrfs on that particular pool member. You may find things resolve themselves there-after. And this would be contextual info on @Hooverdan to-be-created issue.
Just to address the use of Rockstor as a VM: while running Rockstor as a VM may not be an initially-foreseen use case, it’s become a very common setup. I have a 2x 22-core server with 512GB of memory that cost me next-to-nothing (the used server market is a treasure trove of opportunities these days) and it would be immensely wasteful to run just Rockstor on such a computer. I specifically chose Rockstor because it takes advantage of the btrfs file system, while TrueNAS leverages ZFS. The btrfs filesystem is more than happy living on virtual block devices, while ZFS needs direct disk access to perform well (I do use ZFS as the underlying storage system in ProxMox). So Rockstor becomes an excellent candidate for running a dedicated file server as a VM.
I also considered OpenMediaVault since it supports a vast range of filesystems, but ultimately the higher number of features included in Rockstor means I can make it more useful within a single VM rather than having to create more separate VMs to meet my needs. This is a pretty sweet setup.
