I need some help understanding what I'm doing and seeing:

Slackware 14.2 64 bit.
16GB ram
2TB drive

I'm setting up the system to hibernate. So I'm trying to create a swap file large enough to hold system ram, in my case 20GB just for SNG. This is based on the assumption that I actually do need this much swap space, do I?

I create the partition, set it to type 82. I ran mkswap /dev/sda4, and I see:

Setting up swapspace version 1, size = 4 GiB (4320874496 bytes)

Why is it only using 4GB when the partition is much bigger?

So my questions (yes I googled and otherwise searched and searched and did not find the answer maybe I just missed it?)

To hibernate a system with 16GB ram, do I need a swap partition at least that big?

Why, when I make the partition 20GB, mkswap says the actual partition is only 4GB in size?

How, then, (assuming this is necessary) can I make a 20GB partition a swap file such that the entire partition is used?

you forgot to show what or how you created this swap file. it might be just your syntax

2 members found this post helpful.

Read man mkswap.

Sorry for lack of details. This is what I did.

1) use cfdisk to create 20GB partition, type 82
2) mkswap /dev/sda4

That is all - just those two steps. That is where I see "Setting up swapspace version 1, size = 4 GiB"

At that point I stopped because I can't (yet) figure out how to make the swapspace bigger.

Interesting enough, the size option, which man mkswap insists is superfluous, actually seems to work. There must be some default that sets it at 4GB, but I was able to use the size option to force it bigger. Go figure....

From man: "mkswap will use the entire partition or file if it is omitted".

This appears to not be true. If I omit the size, it does not use the entire partition, it only uses 4GB of a 20GB partition.

Formatting as ext4 might not be a bad idea... only to see if you get a 20GB ext4 volume, or if something else is going on.

I have a 16GB swap partition here, so I know that mkswap should be able to handle that (no extra options were needed... made mine just like you have attempted to).

1 members found this post helpful.

I always bump up he size I want because it usually gets set smaller when using
16GB =~ 15.3GB so I'll just tell it something like 16.5GB and take that extra if I get any. When using cfdisk btw.

1 members found this post helpful.

Thank you everyone.

For reasons unknown to me, I use fdisk instead of cfdisk to delete and recreate the partition. And then it worked, it used the entire 20GB. I really have not the slightest clue why. Are there known issues with cfdisk vs fdisk? Or is the phase of the moon sort of thing? Or maybe I just did something stupid with cfdisk and really did not have the swap file I had?

So just to see, I repeated my steps, used cfdisk to create the partition. And this time I get:

Setting up swapspace version 1, size = 20.5 GiB

At which point I realized that this is the Independence Day (In the USA) and I'm sure I can find something better to do than bang my head against the keyboard on a nice day like this trying to create a swap file that now happily works as advertised. It is a balmy 107F (42 C) outside (Phoenix, AZ, USA - 107 is nice considering it was 121 last week), and my swimming pool is calling my name. Maybe the BBQ grill is also clamoring for my attention.

3 members found this post helpful.

My last post seems to have vanished...maybe i stupidly forgot to click "Post Quick Reply"....

So I used fdisk to create the partition instead of cfdisk, and when I did mkswap worked as expected, it used the entire partition. Wtf. Idk. Time to go outside and swim in the pool and BBQ dead animals...

You did say it was sda4, didn't you? Since you were using 'fdisk' I will presume you have the old 'dos' disk-partitions in which case remember there are only 3 primary partitions available and sda4 should be an extended partition which spans the remainder of the disk. maybe (since it not clear from your post), it should've been sda5 ??

Of course, you can also use the 4th partition for whatever you want, but then you can't have any more

1 members found this post helpful.

that's a capital idea -- dead animals taste better cooked.

1 members found this post helpful.

In this case that is OK, I only need the four. But on this topic - fdisk -l shows:

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x05305af2

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 125831167 125829120 60G 83 Linux
/dev/sda2 125831168 251660287 125829120 60G 83 Linux
/dev/sda3 251660288 1910507519 1658847232 791G 83 Linux
/dev/sda4 1910507520 1953525167 43017648 20.5G 82 Linux swap

Are there better ways than the old 'dos' disk-partitions? The reason I did it that way is because that's how I've done it for ummmmm way too many years...

if you're using more partitions than MBR allows.

I've LVM maybe something to look into as well. I do not use that, I still use MBR because I do not slice up my HDD that many times.

well maybe I do

1 members found this post helpful.

To be safe yes plus the video card memory. In reality if you don't use all that memory (RAM + GPU RAM) it swaps only the used memory with compression.

I suppose the kernel flushes caches e.t.c, but I don't examined that, just a guess.

1 members found this post helpful.

What you refer to as dos disk-partitions is actually called MBR partitions (Master Boot Record). This is what allows a max of 4 primary partitions (or 3 primary with an extended partition that allows many more logical partitions). This is an old system that has since been superseded by GPT partitions (GPT stands for GUID Partition Tables, and GUID stands for Global Unique IDentifier -- gotta love acronyms within acronyms).

GPT removes the requirement of no more than 4 primary partitions. It also provides a unique identifier (part of the GUID in the GPT) for each partition, which allows for easier referencing of partitions (although, the kernel added support for kinda unique identifiers for MBR partitions later). GPT partitions are required for UEFI support and is part of the UEFI standard (which is what is replacing BIOS on systems). While UEFI requires GPT, the reverse is not the same. GPT can be used with "legacy" BIOS systems. GPT also supports drives larger than 2TB (although, supposedly MBR will support drives larger than 2TB if you use 4K sectors). In addition, GPT has partition tables backed up at various locations on the drive, so if one part become corrupted, you'll likely be able to recover using another part. I believe MBR only has one place it stores the table.

Overall, other than partitioning, you'll likely notice no difference between the two. I have a mix of GPT and MBR on my desktop, MBR for 2TB and under drives and GPT for any over that. But with any new drives, I'll probably switch to GPT for all future partitioning, because that is going to be the only option soon (plus, almost all my drives are larger than 2TB... my only newer one that isn't is my NVMe drive, but that will be a boot drive, and I'm considering using UEFI, which requires GPT).

There is also LVM that BW-userx mentioned. This is a much more advanced version of the extended partition with logical partitions. It allows easy resizing and moving of partitions, snapshots, and it allows partitions to span across multiple disks. Many people find it easier to encrypt with LVM, although, that isn't a requirement. Unless you have an LVM aware bootloader (according to the Arch Wiki, GRUB is the only bootloader that supports LVM booting), you will need a separate /boot/ partition on an MBR or GPT partitioned disk.

1 members found this post helpful.