Release Engineering

This project is intented for all release related issues (isos, installer, etc), under the umbrella of the ArchLinux Release Engineers
Tasklist

FS#52608 - Unnecessary use of COW space

Attached to Project: Release Engineering
Opened by brent saner (sanerb) - Tuesday, 17 January 2017, 23:46 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Friday, 03 March 2017, 02:37 GMT
Task Type Bug Report
Category ArchISO
Status Waiting on Response
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

On line 28 of the archiso initcpio hook:

truncate -s "${cow_spacesize}" "/run/archiso/cowspace/${cow_directory}/${img_name}.cow"

and line 31 of the same file:

rw_dev=$(losetup --find --show "/run/archiso/cowspace/${cow_directory}/${img_name}.cow")

These steps are an unnecessary limitation if a cow file is not provided/specified to be used. It is a waste of RAM usage otherwise. The default behaviour is a 256MB cow file is created and mounted. However, since ArchISO now uses overlayFS, the squash image itself can be used as the lower via a -o loop mount, and the upper dir can be run entirely in RAM- meaning the only limitation is the RAM on the system rather than an arbitrary file size that must be set during the boot process or ISO creation. What can be (and should be) done instead is if a cow file is not specified on the kernel commandline/${img_name}.cow does not exist, then an upper directory should be created in the initrd (for example, /run/archiso/upper), a work directory created on the initrd (e.g. /run/archiso/work) and then (since initrd is running on memory), one would create an overlayFS mount with those directories at /new_root.
This task depends upon

Comment by brent saner (sanerb) - Tuesday, 17 January 2017, 23:50 GMT
it should also be noted that, while certainly not recommended, this would theoretically allow the ISO to be run on systems with less than 256MB without editing the kernel commandline (assuming they're running from media and not trying to do copytoram).
Comment by brent saner (sanerb) - Tuesday, 17 January 2017, 23:59 GMT
actually, re-reading- i read this wrong. it looks like in that case _dm_snapshot() is not called, BUT for whatever reason the live environment overlay is still limited to 256M even with e.g. 4GB RAM, which seems ludicrous to me for a live CD. I'm not sure where that's being set, but it strikes me as a bit strange.

EDIT: it seems it's set at line 123. If a persistent image is not specified, I'd recommend setting a tmpfs to use the whole size of available RAM. tmpfs will grow (and shrink) as necessary, there should be no need to set this to a hard limit.
Comment by Gerardo Exequiel Pozzi (djgera) - Wednesday, 18 January 2017, 04:05 GMT
what is the final request? is there any limitation here? Waste of RAM where with tmpfs?

In any case you can not boot on system with less than 256MB with XY compression of initramfs, try it ;)

Comment by brent saner (sanerb) - Wednesday, 18 January 2017, 15:28 GMT
bingo! sorry, i wanted to test it first to make sure it'd cause the behaviour i expected.

so, if you do something like this:

--- /usr/lib/initcpio/hooks/archiso 2016-12-21 17:30:46.000000000 -0500
+++ archiso 2017-01-18 10:24:37.113333330 -0500
@@ -194,9 +194,15 @@
echo $(readlink -f ${cow_device}) >> /run/archiso/used_block_devices
mount -o remount,rw "/run/archiso/cowspace"
else
- msg ":: Mounting /run/archiso/cowspace (tmpfs) filesystem, size=${cow_spacesize}..."
- mkdir -p /run/archiso/cowspace
- mount -t tmpfs -o "size=${cow_spacesize}",mode=0755 cowspace /run/archiso/cowspace
+ if [[ "${cow_persistent}" != 'P' ]]; then
+ msg ":: Mounting /run/archiso/cowspace (tmpfs) filesystem, size=${cow_spacesize}..."
+ mkdir -p /run/archiso/cowspace
+ mount -t tmpfs -o "size=${cow_spacesize}",mode=0755 cowspace /run/archiso/cowspace
+ else
+ msg ":: Mounting /run/archiso/cowspace (tmpfs) filesystem..."
+ mkdir -p /run/archiso/cowspace
+ mount -t tmpfs -o mode=0755 cowspace /run/archiso/cowspace
+ fi
fi
mkdir -p -m 0700 "/run/archiso/cowspace/${cow_directory}"


it should do the trick. (might want to test it with persistent cow images though. works fine with copytoram).

result:

dev 2.0G 0 2.0G 0% /dev
run 2.0G 73M 1.9G 4% /run
/dev/sr0 2.4G 2.4G 0 100% /run/archiso/bootmnt
cowspace 2.0G 47M 1.9G 3% /run/archiso/cowspace
/dev/loop0 1.2G 1.2G 0 100% /run/archiso/sfs/airootfs
airootfs 2.0G 47M 1.9G 3% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
tmpfs 2.0G 0 2.0G 0% /tmp
tmpfs 396M 0 396M 0% /run/user/0

edit: and the available RAM isn't affected. :)

[root@bdisk-live ~]# free -m
total used free shared buff/cache available
Mem: 3954 63 3323 118 566 3555
Swap: 0 0 0

Comment by brent saner (sanerb) - Wednesday, 18 January 2017, 16:11 GMT
whoops, that patch is gonna fail because of the munged whitespace. real patch attached.
Comment by Gerardo Exequiel Pozzi (djgera) - Wednesday, 18 January 2017, 17:37 GMT
I am trying to understand what is the last result? why a test on cow_persistent=? Such parameter is only used on dm-snapshot (non-default) mode as documented on docs/.
Looks related to old discussion  FS#45618 

PS: mkdir command is duplicated, patch uses tabs, while archiso use spaces, see .editorconfig/vim last line
Comment by brent saner (sanerb) - Wednesday, 18 January 2017, 17:41 GMT
i've never used persistent images in this manner, so i have no idea- but i PRESUME that's why you're creating a .cow in the first place and limiting the tmpfs size?

regardless; remove the if test if it isn't needed, but putting a size limitation on a tmpfs for a live environment is unnecessary. for an install and for something like /tmp it makes perfect sense, but not for a system designed to be run on RAM entirely.
Comment by brent saner (sanerb) - Wednesday, 18 January 2017, 17:47 GMT
(also- the above patch does not regress  FS#45618  - just tested)
Comment by Gerardo Exequiel Pozzi (djgera) - Thursday, 19 January 2017, 19:25 GMT
Take cowspacesize as safeguard. The 256M limit is just sufficient for releng. If you want to change it, you have two options, at boot time, via parameter, or at runtime via resize tmpfs.

Sure I can remove the limit and left the 75% default for tmpfs and set parameter on releng profile. Such low limit on releng profile has two purposes: as said before is just sufficient for install/rescue procedure, and "avoid" install Arch on RAM, like many users do!, they will see error messages, instead of blank install.
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 20 January 2017, 22:59 GMT
Oh and there is one more thing, in dm-snapshot mode , such limit is for fs that does not support sparse files, like FAT.

Edit: maybe is time to remove dm-snapshot support since overlayfs works fine.
Comment by devnull (0devnull0) - Saturday, 04 March 2017, 22:15 GMT
[...you have two options, at boot time, via parameter, or at runtime via resize tmpfs.]
What about a third option in the build script releng/build or releng/efiboot/loader/entries/archiso-x86_64-cd.conf, where one can specify the size according to his needs?. The later seems easier to just append cow_spacesize=SIZE at the end of the line, so that it reads "options archisobasedir=%INSTALL_DIR% archisolabel=%ARCHISO_LABEL% cow_spacesize=SIZE". Am just not sure if it would work this way and don't know the difference between the files archiso-x86_64-cd.conf and archiso-x86_64-usb.conf, I will have to try it.
Comment by devnull (0devnull0) - Saturday, 04 March 2017, 22:47 GMT
Sorry, page reloaded=> duplicate comment :( Delete plz.
Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 05 March 2017, 13:07 GMT
third? its the same: boot time.
Comment by devnull (0devnull0) - Monday, 06 March 2017, 15:31 GMT
At boot time means to add it to the kernel parameters when the pc actually boots from the install media. What I mean is to have it "built in" by editing the boot loader config file {work_dir}/efiboot/loader/entries/archiso-x86_64-cd.conf. Anyway I tested it by adding cow_spacesize=1G as mentioned before and it worked.

Since this is not really related to what this bug report is about, let's come back to it. Sorry for hijacking.

Loading...