BTRFS postdownloadscript
-
Hello FOG Team,
We are working a lot with the btrfs file system and I found this thread from 2015
https://forums.fogproject.org/topic/5670/btrfs-support/21It seems that imaging a btrfs size with the resizable option is still not possible. (At least I still get an error saying:
Capture error Windows/Linux Partition Count Fail
)However, I was wondering if there is some knowledge base from the last years that came up with a workaround.
I thought about something like shrinking the btrfs partition manually before imaging and expanding it with the help of postdownloadscripts on the client system.
Even though I am not sure how one would tackle this ^^Any help is highly appreciated
Best,
Markus -
@mstabrin I can tell you that both partclone and FOS Linux (the OS that runs on the target computer to capture and deploy images) supports btrfs. What I see is a conflict here with the error message. The error message is dealing with partitions and not the filesystem on the partition.
Does FOG image correctly with specifically single disk non-resizable?
FWIW this is the file systems that partclone supports
ext2 ext3 ext4 fat12 fat16 fat32 hfs+ hfsplus ntfsreloc vfat extfs ntfs xfs fat apfs hfsp btrfs dd -
Hello @george1421 ,
Thank you for answering meWhen I move the Image Type to
Multiple Partition Image - Single Disk (Not resizable) - (2)The imaging is starting and I am also able to successfully deploy the image to another machine…
I have the following partition setup:
sda 2 - 500 MB EFI
sda 3 - 44.5 GB btrfs
sda 1 - 5 GB swapI just saw an error message appear in the (very fast) scrollthrough of the imaging process.
Populating /dev using udev: udevd[3160]: failed to execute '/lib/udev/${exec_prefix}/bin/udevadm' '${exec_prefix}/bin/udevadm trigger -s block -p ID_BTRFS_READY=0': No such file or directory.Is there a way to have a look at the complete log?
It is scrolling very very fast :S -
@mstabrin Although I am not sure exactly I don’t remember anyone working on or asking about this feature.
But if you are keen and help to work on this we might be able to add it.
First we’d need to find a way to figure out how small of a size we can shrink the BTRFS filesystem to. Just found that this was added to btrfs-progs in 2015. So please see on your system if you can get that information via
btrfs filesystem resize [devid:]get_min_sizecommand. If yes then I’d ask you to boot it up into a FOG debug capture task and try as well - just to make sure the btrfs-progs we use can handle it as well. By the way, which version of FOG do you use?sda 2 - 500 MB EFI
sda 3 - 44.5 GB btrfs
sda 1 - 5 GB swapAre you sure about the partition numbers? While I am fairly sure this will work it’s kind of an unusual setup to have SWAP first - at least in most distros.
Aber the boot up message, try:
journalctl -b -
@mstabrin If you schedule another deployment but tick the debug checkbox before you hit the schedule deployment button.
PXE boot the target computer, after a few screens of text you will be dropped to the FOS Linux command prompt on the target computer. Next key in
fogto start the imaging process. The script will pause at each pauseDebug step in the process. You will need to hit enter to continue to the next step. You can exit out of the script at any time by pressing Ctrl-C. The imaging logs will be in /var/logs. If you want to restart the imaging process without rebooting you can just key infogagain and the imaging process will restart. We use this technique when debugging postinit and postdownload scripts. -
@sebastian-roth said in BTRFS postdownloadscript:
Are you sure about the partition numbers? While I am fairly sure this will work it’s kind of an unusual setup to have SWAP first - at least in most distros.
Unless you do some tricky business with the uefi boot manager almost always the EFI partition is expected to be in disk 0 partition 0. You can intentionally make the below partition format work but you need to tweak the uefi manager to look at the second partition since the disk image would not be very portable in this state.
-
Hello @Sebastian-Roth and @george1421 ,
Thank you for all the information!I am using FOG version 1.5.9.
Before I did any further testing I resolved my partition mess:
The allocation of the discs sectors was actually in the correct order, just the naming was messed up by a random allocation order during installation.sda1 - EFI
sda2 - btrfs
sda3 - swapHowever I still get a similar error with - No resizable partitions found):
(I looked at a lot of related threads and those people also posted screenshots of their problems and solutions. However, most of them are unavailable nowadays and therefore the thread not informative anymore. Is posting a screenshot here actually the best method in this case or do you prefer another solution?)So I played around with btrfs resizing and came up with the following inside of the debug mode based on https://unix.stackexchange.com/questions/424758/resize-btrfs-filesystem-to-the-minimum-size-in-a-single-step
mount /dev/sda2 /mnt/bt free_size_original=$(btrfs filesystem usage -b /mnt/bt | grep unallocated | grep -Eo '[0-9]+') mult_val=0.95 free_size=$(echo "scale=0;(${mult_val}*${free_size_original})/1" | bc -l) while ! btrfs filesystem resize -${free_size} /mnt/bt do if [[ ${mult_val} -le 0 ]] then break else mult_val=$(${mult_val} - 0.05) fi free_size=$(echo "scale=0;(${mult_val}*${free_size_original})/1" | bc -l) doneTo bring it back to full size it only needs a:
btrfs filesystem resize max /mnt/btI guess the tricky part now is to allocate the correct partition sizes after the shrink and before the max.
@george1421 I tried to use fthe
fogcommand within the debug mode but only got:
And the next enter sends me back to the command line.
Best,
Markus -
Ok at least I figures out where my problem comes from by reading the code:
https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.upload#L62So btrfs is not yet enabled for possible resizing.
I will see if I can modify the FOS to see what is going on
-
@mstabrin said in BTRFS postdownloadscript:
Hello @Sebastian-Roth and @george1421 ,
Thank you for all the information!I am using FOG version 1.5.9.
Before I did any further testing I resolved my partition mess:
The allocation of the discs sectors was actually in the correct order, just the naming was messed up by a random allocation order during installation.sda1 - EFI
sda2 - btrfs
sda3 - swapHowever I still get a similar error with - No resizable partitions found):
(I looked at a lot of related threads and those people also posted screenshots of their problems and solutions. However, most of them are unavailable nowadays and therefore the thread not informative anymore. Is posting a screenshot here actually the best method in this case or do you prefer another solution?)So I played around with btrfs resizing and came up with the following inside of the debug mode based on https://unix.stackexchange.com/questions/424758/resize-btrfs-filesystem-to-the-minimum-size-in-a-single-step
mount /dev/sda2 /mnt/bt free_size_original=$(btrfs filesystem usage -b /mnt/bt | grep unallocated | grep -Eo '[0-9]+') mult_val=0.95 free_size=$(echo "scale=0;(${mult_val}*${free_size_original})/1" | bc -l) while ! btrfs filesystem resize -${free_size} /mnt/bt do if [[ ${mult_val} -le 0 ]] then break else mult_val=$(${mult_val} - 0.05) fi free_size=$(echo "scale=0;(${mult_val}*${free_size_original})/1" | bc -l) doneTo bring it back to full size it only needs a:
btrfs filesystem resize max /mnt/btI guess the tricky part now is to allocate the correct partition sizes after the shrink and before the max.
@george1421 I tried to use fthe
fogcommand within the debug mode but only got:And the next enter sends me back to the command line.
Best,
MarkusSo I’m working on adding this into the FOS code base and have a lot of code written already.
I’m assuming you have mult_val 0.95 as a percentage to leave an excess room of about 5% during the shrinking? This way the shrink has enough room for any files and what not?
Just trying to understand as we have code for calculating side. I will, for now, have it built for the 0.95 as we know this works. Just want to see if we can use the automated parts already.
Thank you,
-
@mstabrin said in BTRFS postdownloadscript:
I tried to use fthe fog command within the debug mode but only got
Are you using a FOS Linux USB boot drive? I would expect to only see the “Unknown request type :: Null” when booted from a USB stick into FOS Linux without having a corresponding task scheduled on the FOG server. I also noticed that your kernel parameters are incomplete for a capture or deploy (which would also lead to that error message).
-
@mstabrin Here’s what I have, though I have not pushed it into the tree yet:
diff --git a/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.upload b/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.upload index c754273..4d069b4 100755 --- a/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.upload +++ b/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.upload @@ -58,8 +58,9 @@ beginUpload() { dots "Getting Windows/Linux Partition Count" countPartTypes "$hd" "ntfs" "ntfscnt" countPartTypes "$hd" "extfs" "extfscnt" + countPartTypes "$hd" "btrfs" "btrfscnt" countPartTypes "$hd" "*" "partscnt" - if [[ $ntfscnt -eq 0 && $extfscnt -eq 0 ]]; then + if [[ $ntfscnt -eq 0 && $extfscnt -eq 0 && $btrfscnt -eq 0 ]]; then echo "Failed" debugPause handleError "No resizable partitions found ($0)\n Args Passed: $*" @@ -70,6 +71,8 @@ beginUpload() { debugPause echo " * EXTFS Partition count of: $extfscnt" debugPause + echo " * BTRFS Partition count of: $btrfscnt" + debugPause echo " * Total Partition count of: $partscnt" debugPause case $osid in diff --git a/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh b/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh index 959be5f..0f1d64e 100644 --- a/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh +++ b/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh @@ -258,6 +258,31 @@ expandPartition() { ;; esac ;; + btrfs) + # Based on info from @mstabrin on forums.fogproject.org + if [[ ! -d /tmp/btrfs ]]; then + mkdir /tmp/btrfs >>/tmp/btfrslog.txt 2>&1 + if [[$? -gt 0 ]]; then + echo "Failed" + debugPause + handleError "Could not create /tmp/btrfs (${FUNCNAME[0]})\n Info: $(cat /tmp/btrfslog.txt)\n Args Passed: $*" + fi + fi + mount $part /tmp/btrfs >>/tmp/btrfslog.txt 2>&1 + if [[ $? -gt 0 ]]; then + echo "Failed" + debugPause + handleError "Could not mount $part to /tmp/btrfs (${FUNCNAME[0]})\n Info: $(cat /tmp/btrfslog.txt)\n Args Passed: $*" + fi + btrfs filesystem resize max /tmp/btrfs >>/tmp/btrfslog.txt 2>&1 + if [[ $? -gt 0 ]]; then + echo "Failed" + debugPause + handleError "Could not resize btrfs partition (${FUNCNAME[0]})\n Info: $(cat /tmp/btrfslog.txt)\n Args Passed: $*" + fi + umount $part /tmp/btrfs >/dev/null 2>&1 + echo "Done" + ;; *) echo " * Not expanding ($part -- $fstype)" debugPause @@ -597,6 +622,31 @@ shrinkPartition() { ;; esac ;; + btrfs) + # Based on info from @mstabrin on forums.fogproject.org + # https://forums.fogproject.org/topic/15159/btrfs-postdownloadscript/3 + if [[ ! -d /tmp/btrfs ]]; then + mkdir /tmp/btrfs >>/tmp/btfrslog.txt 2>&1 + if [[$? -gt 0 ]]; then + echo "Failed" + debugPause + handleError "Could not create /tmp/btrfs (${FUNCNAME[0]})\n Info: $(cat /tmp/btrfslog.txt)\n Args Passed: $*" + fi + fi + mount $part /tmp/btrfs >>/tmp/btrfslog.txt 2>&1 + if [[ $? -gt 0 ]]; then + echo "Failed" + debugPause + handleError "Could not mount $part to /tmp/btrfs (${FUNCNAME[0]})\n Info: $(cat /tmp/btrfslog.txt)\n Args Passed: $*" + fi + local free_size_original=$(btrfs filesystem usage -b /tmp/btrfs | grep unallocated | grep -Eo '[0-9]+') + local mult_val=0.95 + local free_size=$(echo "scale=0;(${mult_val}*${free_size_original})/1" | bc -l) + while ! btrfs filesystem resize -${free_size} /tmp/btrfs; do + [[ ${mult_val} -le 0 ]] && break || mult_val=$(${mult_val} - 0.05) + free_size=$(echo "scale=0;(${mult_val}*${free_size_original})/1" | bc -l) + done + ;; *) echo " * Not shrinking ($part $fstype)" ;;From there, you can test these changes by updating the relevant files and placing using postinit scripts or you can extract the init with something like:
cd /var/www/fog/service/ipxe mkdir tmp cp init.xz init_orig.xz xz -d init.xz mount -o loop init tmpEdit the file tmp/bin/fog.upload
Edit the file in tmp/usr/share/fog/lib/funcs.shThen:
umount tmp xz -C crc32 -9 initLet us know if this works as intended or any changes as needed.
Thanks again!
-
@Tom-Elliott Thank you for this amazing information I will directly try it tomorrow!
Regarding the 95%: Yes it seems that when I used 100% it could not resize it. 95% seemed to work in my case though. Possibly due to some overhead when the data is fragmented on the drive. This incremental test to resize was recommended in the post I linked.
Looking forward to work with you on the topic
@george1421 I asked for a debug task on the machine and it is booting into it.
I am using a virtual machine from vmware, maybe that is the reason for the missing information?
-
@mstabrin @Tom-Elliott Seems like you have pushed this a lot forward. Well done.
Just allow me one comment about the code:
while ! btrfs filesystem resize ...Having worked on those kind of scripts for a long time this looks really scary to me. Running such a resize command in a loop will be causing trouble sooner or later I am sure. I am wondering why this command should return with a non-zero return code but still should be called again. Does btrfs resize need to be done in steps. I really doubt so.
-
@Tom-Elliott One more thing I just remembered. We do have a “global” setting to set the percentage of how small we size down the partition (code ref for NTFS and EXT) and I think we should go along the same line with btrfs as well.
The percentage can be set via FOG web UI -> FOG Configuration -> FOG Settings -> General Settings -> CAPTURERESIZEPCT
-
@sebastian-roth I knew about the capture resize pct issue, and just was verifying with mstabrin that everything was configured appropriately and the 95% was the use of free space to shrink to.
Modified with using the database capture resize percent is now used here:
diff --git a/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.upload b/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.upload index c754273..4d069b4 100755 --- a/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.upload +++ b/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.upload @@ -58,8 +58,9 @@ beginUpload() { dots "Getting Windows/Linux Partition Count" countPartTypes "$hd" "ntfs" "ntfscnt" countPartTypes "$hd" "extfs" "extfscnt" + countPartTypes "$hd" "btrfs" "btrfscnt" countPartTypes "$hd" "*" "partscnt" - if [[ $ntfscnt -eq 0 && $extfscnt -eq 0 ]]; then + if [[ $ntfscnt -eq 0 && $extfscnt -eq 0 && $btrfscnt -eq 0 ]]; then echo "Failed" debugPause handleError "No resizable partitions found ($0)\n Args Passed: $*" @@ -70,6 +71,8 @@ beginUpload() { debugPause echo " * EXTFS Partition count of: $extfscnt" debugPause + echo " * BTRFS Partition count of: $btrfscnt" + debugPause echo " * Total Partition count of: $partscnt" debugPause case $osid in diff --git a/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh b/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh index 959be5f..b29e5ca 100644 --- a/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh +++ b/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh @@ -258,6 +258,31 @@ expandPartition() { ;; esac ;; + btrfs) + # Based on info from @mstabrin on forums.fogproject.org + if [[ ! -d /tmp/btrfs ]]; then + mkdir /tmp/btrfs >>/tmp/btfrslog.txt 2>&1 + if [[$? -gt 0 ]]; then + echo "Failed" + debugPause + handleError "Could not create /tmp/btrfs (${FUNCNAME[0]})\n Info: $(cat /tmp/btrfslog.txt)\n Args Passed: $*" + fi + fi + mount $part /tmp/btrfs >>/tmp/btrfslog.txt 2>&1 + if [[ $? -gt 0 ]]; then + echo "Failed" + debugPause + handleError "Could not mount $part to /tmp/btrfs (${FUNCNAME[0]})\n Info: $(cat /tmp/btrfslog.txt)\n Args Passed: $*" + fi + btrfs filesystem resize max /tmp/btrfs >>/tmp/btrfslog.txt 2>&1 + if [[ $? -gt 0 ]]; then + echo "Failed" + debugPause + handleError "Could not resize btrfs partition (${FUNCNAME[0]})\n Info: $(cat /tmp/btrfslog.txt)\n Args Passed: $*" + fi + umount $part /tmp/btrfs >/dev/null 2>&1 + echo "Done" + ;; *) echo " * Not expanding ($part -- $fstype)" debugPause @@ -597,6 +622,32 @@ shrinkPartition() { ;; esac ;; + btrfs) + # Based on info from @mstabrin on forums.fogproject.org + # https://forums.fogproject.org/topic/15159/btrfs-postdownloadscript/3 + if [[ ! -d /tmp/btrfs ]]; then + mkdir /tmp/btrfs >>/tmp/btfrslog.txt 2>&1 + if [[$? -gt 0 ]]; then + echo "Failed" + debugPause + handleError "Could not create /tmp/btrfs (${FUNCNAME[0]})\n Info: $(cat /tmp/btrfslog.txt)\n Args Passed: $*" + fi + fi + mount $part /tmp/btrfs >>/tmp/btrfslog.txt 2>&1 + if [[ $? -gt 0 ]]; then + echo "Failed" + debugPause + handleError "Could not mount $part to /tmp/btrfs (${FUNCNAME[0]})\n Info: $(cat /tmp/btrfslog.txt)\n Args Passed: $*" + fi + local free_size_original=$(btrfs filesystem usage -b /tmp/btrfs | grep unallocated | grep -Eo '[0-9]+') + local fsize_pct=$(calculate "${percent}/100") + local mult_val=$(calculate "1-${fsize_pct}") + local free_size=$(echo "scale=0;(${mult_val}*${free_size_original})/1" | bc -l) + while ! btrfs filesystem resize -${free_size} /tmp/btrfs; do + [[ ${mult_val} -le 0 ]] && break || mult_val=$(${mult_val} - ${fsize_pct}) + free_size=$(echo "scale=0;(${mult_val}*${free_size_original})/1" | bc -l) + done + ;; *) echo " * Not shrinking ($part $fstype)" ;;Then for the while loop, I’m with you, but this is according to the following article:
https://unix.stackexchange.com/questions/424758/resize-btrfs-filesystem-to-the-minimum-size-in-a-single-stepBasically it shrinks and continues to shrink in steps until it cannot shrink. BTRFS is not very nice about shrinking. You can expand until your drive is in the middle of the yard, but shrinking, while now possible, is still relatively new to BTRFS. It is one of the reasons we didn’t add BTRFS to the shrinking when BTRFS started to become popular. It literally could not be shrunk.
-
@tom-elliott @mstabrin In that stackexchange topic they mention
while sudo btrfs filesystem resize .... Why iswhile ! btrfs filesystem resize ...used in this script - reversed logic?@mstabrin said:
Populating /dev using udev: udevd[3160]: failed to execute ‘/lib/udev/${exec_prefix}/bin/udevadm’ ‘${exec_prefix}/bin/udevadm trigger -s block -p ID_BTRFS_READY=0’: No such file or directory.
Good you posted the pictures. I didn’t expect that message to come from our FOS Linux. Haven’t seen this message before I think. It’s probably to do with us using
partprobea couple of times. No idea which file or directory is not found. I think it’s save to ignore those for now. Seems to be a known issue in udev rules provided by eudev package used by buildroot which we build our inits from. -
@sebastian-roth I don’t know, @mstabrin had already tested it. I don’t have any BTRFS to test with, so I just used what was working (with minor adjustments for error controls) I don’t really know why while ! btrfs filesystem resize … is used, I just knew it was already working at least in this case.
-
Hello @Sebastian-Roth ,
Populating /dev using udev: udevd[3160]: failed to execute ‘/lib/udev/${exec_prefix}/bin/udevadm’ ‘${exec_prefix}/bin/udevadm trigger -s block -p ID_BTRFS_READY=0’: No such file or directory.
I realised that there are similiar udev related messages in the logs of our VMs and I checked the other VMs and this seems to be a vmware related issue but should not cause too much trouble
Feb 10 08:22:40 fog-server2021 multipathd[745]: sda: add missing path Feb 10 08:22:40 fog-server2021 multipathd[745]: sda: failed to get udev uid: Invalid argument Feb 10 08:22:40 fog-server2021 multipathd[745]: sda: failed to get sysfs uid: Invalid argument Feb 10 08:22:40 fog-server2021 multipathd[745]: sda: failed to get sgio uid: No such file or directoryMaybe it is related?
Regarding
while ! btrfs filesystem resize ...:My reasoning was simply based on the assumption that it happens more often that the unallocated value is not too far away from the truth than the other way around.
Therefore, it would require less steps to reduce the value of provided unallocated free space to a value that it works, than incrementally decreasing the overall free space until it no longer works, i.e., I am asking for: do you have 4GB free? no? Do you have 3 GB free? instead of: do you still have 200MB free? yes? do you still have 200 MB free? As suggested in the post.While the latter method ensures that you really shrink the partition to its minimum (with a 200MB margin in this case) for my Ubuntu golden image with 5GB occupied on an at least 50GB hard drive I thought that even 10GB occupied should be enough for imaging (and later deployment on other at least 50GB hard drives) since it is expanded anyway during deployment.
As @Tom-Elliott said, shrinking is usually not what btrfs is good at due to fragmentation of snapshots in the images as far as I know. Therefore, I fear that an incremental search is the way to go in this case and a loop unavoidable.But of course it makes sense to optimise the space usage since 95% of a huge drive can of course be larger than the total capacity of a small one.
I did not know about the global CAPTURERESIZEPCT value though and that makes things more consistent
So we should be able to refine the method once things are working properly from the shrink / expand perspective to optimise the workflow@Tom-Elliott Thank you for the coding, I will give it a try now
fingers crossed -
Hello everybody,
I needed to get myself into the FOS environment yesterday, BUT it works now (At least for my usecase 
)Are you using a FOS Linux USB boot drive? I would expect to only see the “Unknown request type :: Null” when booted from a USB stick into FOS Linux without having a corresponding task scheduled on the FOG server. I also noticed that your kernel parameters are incomplete for a capture or deploy (which would also lead to that error message).
This happened because I used the normal Debug task and not the Capture - Debug task.
Using the Caputer - Debug made things work as you described them@Tom-Elliott
I needed to make some minor changes to your suggested changes, but it was amazingly helpful to know which parts to look atfuncs.sh (based on what you send me):
--- funcs.sh_ori 2021-02-10 13:25:08.000000000 +0100 +++ funcs.sh 2021-02-11 09:08:31.660652070 +0100 @@ -255,15 +255,15 @@ fi echo "Done" ;; esac ;; - extfs) + btrfs) # Based on info from @mstabrin on forums.fogproject.org if [[ ! -d /tmp/btrfs ]]; then mkdir /tmp/btrfs >>/tmp/btfrslog.txt 2>&1 - if [[$? -gt 0 ]]; then + if [[ $? -gt 0 ]]; then echo "Failed" debugPause handleError "Could not create /tmp/btrfs (${FUNCNAME[0]})\n Info: $(cat /tmp/btrfslog.txt)\n Args Passed: $*" fi fi @@ -625,11 +625,11 @@ btrfs) # Based on info from @mstabrin on forums.fogproject.org # https://forums.fogproject.org/topic/15159/btrfs-postdownloadscript/3 if [[ ! -d /tmp/btrfs ]]; then mkdir /tmp/btrfs >>/tmp/btfrslog.txt 2>&1 - if [[$? -gt 0 ]]; then + if [[ $? -gt 0 ]]; then echo "Failed" debugPause handleError "Could not create /tmp/btrfs (${FUNCNAME[0]})\n Info: $(cat /tmp/btrfslog.txt)\n Args Passed: $*" fi fi @@ -638,16 +638,18 @@ echo "Failed" debugPause handleError "Could not mount $part to /tmp/btrfs (${FUNCNAME[0]})\n Info: $(cat /tmp/btrfslog.txt)\n Args Passed: $*" fi local free_size_original=$(btrfs filesystem usage -b /tmp/btrfs | grep unallocated | grep -Eo '[0-9]+') - local mult_val=0.95 - local free_size=$(echo "scale=0;(${mult_val}*${free_size_original})/1" | bc -l) - while ! btrfs filesystem resize -${free_size} /tmp/btrfs; do - [[ ${mult_val} -le 0 ]] && break || mult_val=$(${mult_val} - 0.05) - free_size=$(echo "scale=0;(${mult_val}*${free_size_original})/1" | bc -l) + local fsize_pct=$(calculate_float "${percent}/100") + local mult_val=$(calculate_float "1-${fsize_pct}") + local free_size=$(calculate "${mult_val}*${free_size_original}") + while ! btrfs filesystem resize -${free_size} /tmp/btrfs >>/tmp/btrfslog.txt 2>&1; do + [[ $(echo "${mult_val} <= 0" | bc -l) -gt 0 ]] && break || mult_val=$(calculate_float "${mult_val}-0.05") + free_size=$(calculate "${mult_val}*${free_size_original}") done + umount /tmp/btrfs >>/tmp/btrfslog.txt 2>&1 ;; *) echo " * Not shrinking ($part $fstype)" ;; esac @@ -2421,5 +2423,8 @@ } # Calculates information calculate() { echo $(awk 'BEGIN{printf "%.0f\n", '$*'}') } +calculate_float() { + echo $(awk 'BEGIN{printf "%f\n", '$*'}') +}Small changelog:
- I needed to add a new
calculate_floatfunction to make the float calculations work - Minor syntax problems in the if statements and missing whitespaces
- btrfs instead of extfs in shrinkPartition
- Fixed the if condition inside the loop.
- Used the
calculateandcalculate_floatinstead of my suggestedbc -l - Used a fixed decrement of 5%, as we try to be as close to the
percentvalue as possible. Otherwise the mechanism would break if thepercentvalue is large. - Unmount the btrfs file system after shrinking to allow for partition shrinking later.
fog.sh (based on what you send me):
--- fog.upload_ori 2021-02-10 13:22:20.000000000 +0100 +++ fog.upload 2021-02-11 08:44:34.415100613 +0100 @@ -42,11 +42,12 @@ part_number=0 for part in $parts; do fsTypeSetting "$part" getPartitionNumber "$part" case $fstype in - ntfs|extfs) + ntfs|extfs|btrfs) + #ntfs|extfs) continue ;; *) fixed_size_partitions="$fixed_size_partitions:$part_number" ;;- Added btrfs to the shrinkable partition list
Thank you for all the help
If you need more information from me, feel free to ask - I needed to add a new
-
@mstabrin While this won’t make the inits readily available quite yet, I have decided to push the code into github. Thanks for the assist and finding of bugs, it made adding this feature quite a lot faster.