I have a z/linux SLES12 system built with the btrfs file system.
I successfully add and resize the file system.
When I reboot the system I hit an endless loop on the system with a “start job”.
[CODE]btrfs device add /dev/dasda /
btrfs filesystem resize max /
A start job is running for dev-disk-by\x2duuid-b2732… 5s [/CODE]
I am able to do this with a system built with the xfs file system.
I am thinking that maybe the device needs to be added to the kernel!?
Just as a note, there is a System-Z specific forum that may be useful to
use for these issues that, to me, sound like they could be platform-specific.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
I have found two methods that work for resizing the btrfs “/” filesystem.
The two methods are to update /etc/fstab or update the kernel and then update grub2.
I have a couple of questions.
1 - When I extend a xfs filesystem I do not need to update the kernel or /etc/fstab.
why is this needed for btrfs?
2 - When I update the kernel I had to specify both disks.
The IPL volume and the dasd the I use to extend the filesystem.
I thought it odd that I had to specify the IPL volume.
Is there a reason for this? The 3120 address is the IPL volume.
Note: this is probably true for updating /etc/fstab but I did not try this variation.
[CODE]Method 1: Update /etc/fstab
cio_ignore -r 0.0.0604
chccwdev -e 0.0.0604
lsdasd - check dasd location
dasdfmt -b 4096 -f /dev/dasdb -p -y
fdasd -sa /dev/dasdb
Yast - make device persistent
reboot
btrfs device add /dev/dasda1 /
btrfs filesystem resize max /
Update /etc/fstab
UUID=b273239f-1943-4607-ad44-2e007624ee1b / btrfs device=/dev/dasda1,device=/dev/dasdb3 0 0
grub2-install
Method 2: Update the kernel.
cio_ignore -r 0.0.0604
chccwdev -e 0.0.0604
lsdasd - check dasd location
dasdfmt -b 4096 -f /dev/dasdb -p -y
fdasd -sa /dev/dasdb
Yast - make device persistent
reboot
btrfs device add /dev/dasda1 /
btrfs filesystem resize max /
Yast update kernel parameters - !0.0.0604,!0.0.3120 and dasd=0604,3120
grub2-install[/CODE]
On 02/02/2017 06:54 AM, mikenash wrote:[color=blue]
I have found two methods that work for resizing the btrfs “/”
filesystem.
The two methods are to update /etc/fstab or update the kernel and then
update grub2.[/color]
I think you mean you are updating the ‘kernel’ line of the boot parameters
as used by grub2, so the kernel itself is not really changing but the
options passed to it by the boot loader are. The kernel is a bunch of
files on disk, and those are in a few RPMs, and you are not changing those.
[color=blue]
I have a couple of questions.
1 - When I extend a xfs filesystem I do not need to update the kernel or
/etc/fstab.
why is this needed for btrfs?[/color]
I do not know yet, but my theory is below.
[color=blue]
2 - When I update the kernel I had to specify both disks.[/color]
The boot loader (grub2), I think you mean.
[color=blue]
Code:
Method 1: Update /etc/fstabcio_ignore -r 0.0.0604
chccwdev -e 0.0.0604
lsdasd - check dasd location
dasdfmt -b 4096 -f /dev/dasdb -p -y
fdasd -sa /dev/dasdb
Yast - make device persistent
reboot
btrfs device add /dev/dasda1 /
btrfs filesystem resize max /
Update /etc/fstab
UUID=b273239f-1943-4607-ad44-2e007624ee1b / btrfs device=/dev/dasda1,device=/dev/dasdb3 0 0
grub2-installMethod 2: Update the kernel.
cio_ignore -r 0.0.0604
chccwdev -e 0.0.0604
lsdasd - check dasd location
dasdfmt -b 4096 -f /dev/dasdb -p -y
fdasd -sa /dev/dasdb
Yast - make device persistent
reboot
btrfs device add /dev/dasda1 /
btrfs filesystem resize max /
Yast update kernel parameters - !0.0.0604,!0.0.3120 and dasd=0604,3120
grub2-install
--------------------[/color]
Looking at what you have there, and since you are having to “update”
things, something is apparently changing. What changed in those lines?
The disk UUID? The disk number? Something else? I believe that UUIDs
are usually written to the partition so that they can be found regardless,
and that should not change, but maybe it did in your case for some reason
requiring you to update things that point to the UUIDs, Alternatively,
perhaps something about the resize process actually created new space and
moved things over, though that seems extreme and unlikely. Maybe the
device name (not the UUID) changed, and while the device could be found by
UUID the other settings were off enough to prevent proper functionality.
This is all new to me, and I’m guessing Mainframe-specific stuff, but my
mainframe is still missing for me to test. 
Normally resizing should not require changing things that point to the
disks. My guess at why this worked with XFS: the pointers to the
partition were different, maybe by name or something that did not change.
Still seems odd, but without seeing a before/after with XFS along with the
before (missing) and after (above) of BtrFS, I’m just guessing.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…