| Message ID | 20250320-initrd-autoresize-v1-1-a9a5930205f8@cyberus-technology.de (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] initrd: resize /dev/ram as needed | expand |
On Thu, Mar 20, 2025 at 08:46:14PM +0100, Julian Stecklina via B4 Relay wrote: > From: Julian Stecklina <julian.stecklina@cyberus-technology.de> > > When the initrd doesn't fit into the RAM disk, we currently just die. > This is unfortunate, because users have to manually configure the RAM > disk size for no good reason. It also means that the kernel command > line needs to be changed for different initrds, which is sometimes > cumbersome. > > Attempt resizing /dev/ram to fit the RAM disk size instead. This makes > initrd images work a bit more like initramfs images in that they just > work. > > Of course, this only works, because we know that /dev/ram is a RAM > disk and we can resize it freely. I'm not sure whether I've used the > blockdev APIs here in a sane way. If not, please advise! Just use an initramfs and avoid all these problems.
Hi Christoph, On Fri, 2025-03-21 at 06:01 +0100, Christoph Hellwig wrote: > On Thu, Mar 20, 2025 at 08:46:14PM +0100, Julian Stecklina via B4 Relay wrote: > > From: Julian Stecklina <julian.stecklina@cyberus-technology.de> > > > > When the initrd doesn't fit into the RAM disk, we currently just die. > > This is unfortunate, because users have to manually configure the RAM > > disk size for no good reason. It also means that the kernel command > > line needs to be changed for different initrds, which is sometimes > > cumbersome. > > > > Attempt resizing /dev/ram to fit the RAM disk size instead. This makes > > initrd images work a bit more like initramfs images in that they just > > work. > > > > Of course, this only works, because we know that /dev/ram is a RAM > > disk and we can resize it freely. I'm not sure whether I've used the > > blockdev APIs here in a sane way. If not, please advise! > > Just use an initramfs and avoid all these problems. > Well, as Gao Xiang put it in the other mail: CPIO is somewhat inflexible. So here we are. :) That being said, I saw that the RAM disk code allocates memory on demand, so there is no downsize to set the default size to 1G and not bother with resizing it. Problem solved! Patch not needed. Julian
diff --git a/init/do_mounts_rd.c b/init/do_mounts_rd.c index ac021ae6e6fa78c7b7828a78ab2fa3af3611bef3..5ae3639765199294a07a9b9025b7b43265370896 100644 --- a/init/do_mounts_rd.c +++ b/init/do_mounts_rd.c @@ -183,6 +183,24 @@ static unsigned long nr_blocks(struct file *file) return i_size_read(inode) >> 10; } +static int resize_ramdisk(const char *devname, u64 new_size_blocks) +{ + struct block_device *bdev; + struct file *bdev_file; + + bdev_file = bdev_file_open_by_path(devname, BLK_OPEN_READ, NULL, NULL); + if (IS_ERR(bdev_file)) + goto err; + + bdev = file_bdev(bdev_file); + set_capacity(bdev->bd_disk, (new_size_blocks * BLOCK_SIZE) / SECTOR_SIZE); + + fput(bdev_file); + return 0; +err: + return -1; +} + int __init rd_load_image(char *from) { int res = 0; @@ -219,9 +237,10 @@ int __init rd_load_image(char *from) * the number of kibibytes of data to load into a ramdisk. */ rd_blocks = nr_blocks(out_file); - if (nblocks > rd_blocks) { - printk("RAMDISK: image too big! (%dKiB/%ldKiB)\n", + if (nblocks > rd_blocks && resize_ramdisk("/dev/ram", nblocks)) { + printk("RAMDISK: image too big and couldn't resize! (%dKiB/%ldKiB)\n", nblocks, rd_blocks); + goto done; }