-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Determine how we extend partitions on boot #45
Comments
CL uses this service: https://github.com/coreos/init/blob/master/systemd/system/extend-filesystems.service to run this script: https://github.com/coreos/init/blob/master/scripts/extend-filesystems |
Assuming you mean both partitions and filesystems. Ignition can do partitions natively as of 2.3.0-experimental (and we can include logic for this the base config on FCOS (n.b. we'll need to fix the appending logic to allow overriding that)). Being able to resize the root partition was one of the motivations behind the partitioning rework. Filesystems can be resized on first boot via system units. Things I'd want to change about the extend-filesystems script: make it an instantiated unit and enable it as part of the Ignition base config. |
We could also have whatever sit on top of Ignition (e.g. ct) have some sugar for writing out that unit too. I'd like to keep that sugar out of Ignition itself, but if the FCOS |
Related? openshift/os#192 |
Yeah, the disks stage is definitely needed for that, but we need that anyway. |
so it sounds like we'll use something temporary for now (see colin's PR) and plan for ignition disks in the future |
Been thinking about this a lot. There is one potential hiccup; disks can have aliases. |
A couple of things that I think may not be obvious from current CL setup:
|
so you are just stating how it is today in CL. Are you advocating for those same behaviors in FCOS or was that just an FYI? |
@dustymabe mostly a FYI, as I fear those bits were overlooked (and may be partially relevant). I currently don't have a good opinion on how we should do this. At the moment I think we should keep the last point (decoupling from ignition config), we may do a similar variation of the second point (perhaps using a bit in the partition attributes instead of a type GUID), and I'm neutral on how often we should try to resize (perhaps only on first-boot is enough and saner?). So I'd be happy to see more brainstorming here. |
Several thoughts and opinions and a proposal:
Another thought: What if we did the resize before Ignition disks in the initramfs? I'm not sure what I think of this idea.
|
Is there any update about extend partitions on boot? variant: fcos
version: 1.0.0
systemd:
units:
- name: extend-filesystems.service
enabled: true
contents: |
[Unit]
Description=Extend Filesystems
Before=local-fs.target
[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/local/bin/extend-data-filesystems
StandardOutput=journal+console
storage:
files:
- path: /usr/local/bin/extend-data-filesystems
mode: 0777
contents:
inline: |
#!/bin/bash
# Automatic resize of xfs, btrfs and ext4 filesystems.
#
set -o pipefail
declare -a DEV_LIST
mapfile DEV_LIST < <(lsblk -P -o NAME,PARTTYPE,FSTYPE,MOUNTPOINT,LABEL,KNAME,PKNAME)
for dev_info in "${DEV_LIST[@]}"; do
eval "$dev_info"
NAME=${NAME//\!//}
if [[ "${LABEL}" != data* ]] || \
[[ -z "${NAME}" ]] || \
[[ -z "${MOUNTPOINT}" ]] || \
[[ ! -w "${MOUNTPOINT}" ]] || \
[[ "${FSTYPE}" != "btrfs" && "${FSTYPE}" != "ext4" && "${FSTYPE}" != "xfs" ]]
then
continue
fi
echo "* try to resize: ${NAME}: ${LABEL}"
device="/dev/${NAME}"
old_size=$(blockdev --getsz "${device}")
growpart "/dev/${PKNAME}" 1
# Only resize filesystem if the partition changed
if [[ "${old_size}" -eq $(blockdev --getsz "${device}") ]]; then
continue
fi
case "${FSTYPE}" in
"btrfs")
# map the device name to the btrfs device id
device_id=$(btrfs filesystem show -d "${device}" | \
awk -v "d=${device}" -e 'd == $8 {print $2}')
btrfs filesystem resize "${device_id}:max" "${MOUNTPOINT}"
;;
"ext4")
resize2fs "${device}"
;;
"xfs")
xfs_growfs "${MOUNTPOINT}"
;;
esac
done |
This is a pretty old design issue. It was mentioned higher up, but worth highlighting again: we do extend at least the root partition (and the containing filesystem) now using For other partitions, you can use Ignition itself to do that (though see the caveat in coreos/ignition#924 about holes). But yes, you do still need a systemd unit to grow filesystems. I'm going to close this issue now since I think it's not well-defined enough anymore. Let's have separate issues with more focused RFEs instead if needed? (But anyone feel free to reopen if you disagree!)
Hmm, I think you can just switch the |
We've used a tool called container-storage-setup that called out to cloud-utils-growpart in the past in Atomic Host. See https://pagure.io/atomic-wg/issue/384
In CL was this handled by ignition-disks ?
The text was updated successfully, but these errors were encountered: