btrfs swap partition

[oldgeek]

I have recently installed Kubuntu 18.04 on my desktop using the btrfs file system and only one partition, labeled sda1. I keep reading in posts about a swap partition for btrfs, which I don't have (at least it doesn't show up on KDE partition manager). Do I need to have that? I don't ever suspend the computer--I turn it off when I'm finished. If I do need that, how big should it be? How do I create it using either KDE partition man. or Gparted? It would be nice if I didn't have to do anything, of course!

[vinnywright]

how much RAM dose the box have ,,,,,you may not need one at all if it's 8 or more GB's and you dont ever want to suspend .

VINNY

[GreyGeek]

I have recently installed Kubuntu 18.04 on my desktop using the btrfs file system and only one partition, labeled sda1. I keep reading in posts about a swap partition for btrfs, which I don't have (at least it doesn't show up on KDE partition manager). Do I need to have that? I don't ever suspend the computer--I turn it off when I'm finished. If I do need that, how big should it be? How do I create it using either KDE partition man. or Gparted? It would be nice if I didn't have to do anything, of course!

What VINNY says about suspending: +1

No. Btrfs does NOT use a swap file or a swap partition. A swap partition may be useful for some applications which might use one, but off hand I cannot think of any that do.

Oshunluver discusses resizing here.

If you've devoted your entire HD to the /dev/sda1 partition and have no room to create a swap partition you can shrink the Btrfs pool size by using the resize command:

       $ btrfs filesystem resize -1G /path

       $ btrfs filesystem resize 1:-1G /path

       Shrink size of the filesystem’s device id 1 by 1GiB. The first syntax expects a device with id 1 to exist, otherwise fails. The second is equivalent and more explicit. For a single-device filesystem it’s typically not necessary to specify the devid though.

       $ btrfs filesystem resize max /path

       $ btrfs filesystem resize 1:max /path

       Let’s assume that devid 1 exists, the filesystem does not occupy the whole block device, eg. it has been enlarged and we wan the grow the  filesystem. Simply using max as size we will achieve that.

           Note
           There are two ways to minimize the filesystem on a given device. The btrfs inspect-internal min-dev-size command, or iteratively shrink in steps.

EXIT STATUS
       btrfs filesystem returns a zero exit status if it succeeds. Non zero is returned in case of failure.

So, you could do something like:
sudo -i
mount /dev/sda1 /mnt
btrfs filesystem resize -NG /mnt
where N is the size you want the swap partition to be.
N can be the size of RAM + a small amount. If you have 8GB of RAM I'd make the swap 9GB. If you had 16GB of RAM I'd make it 18GB, etc...
After the resize is done successfully you can umount /mnt, exit sudo and exit the Konsole.
Then open kpartition and take the freed up raw space and format it as a swap partition. If the swap partition is /dev/sda2 then it can be activated in a Konsole using
sudo swapon /dev/sda2

To enable the device for paging:
sudo swapon /dev/sdxy
To enable this swap partition on boot, add an entry to fstab:

UUID=<UUID> none swap defaults 0 0
where the <UUID> is taken from the command:
lsblk -no UUID /dev/sdxy
Tip: UUIDs and LABELs should be favoured over the use of the device names given by the kernel as the device order could change in the future. See: fstab.

[oshunluvr]

Technically, this is a bug in the installer (as usual). BTRFS cannot support swap files, but the devs have ignored that and still create a swap file when installing using btrfs.

Either disable swap and delete the swap file and don't use swap or create a swap partition and mount it in fstab.

[oldgeek]

I don't have a swap file as far as I can tell--it doesn't appear anywhere. I have 6 GB RAM and a 500 GB HDD on my 'box' and an i3 processor. Works well. If no one can think of a use I might have for a swap partition, I'll just leave well enough alone. I've mounted my btrfs in fstab and have two snapshots in /subvol (@ and @home, as per Greygeek's advice) so everything seems normal so far. I just wanted to know if a swap partition was necessary. If I ever need one, at least I know where to look now.

[oldgeek]

I forgot to say thanks. I really appreciate the help from this forum.

[GreyGeek]

@ and @home are not snapshots, they are subvolumes of <ROOT_FS>,
Don't forget to make at least two snapshots, one of @ and one of @home (@yyyymmdd and @homeyyyymmdd). So, you should have at least two snapshots. Creating a subdirectory (I use /mnt/snapshots) as a place to store them will keep things tidy and in order.

[oshunluvr]

If a swapfile or swap partition were created, it would be listed in /etc/fstab. If it's there, add a # to the beginning of the line in fstab and type:

sudo swapoff -a

[oldgeek]

Greygeek, I do have the snapshots, but didn't mention the name I gave them. Which brings me to a point: you identify the snapshots by date--is that required, or just good common sense? I just used @snapshot1, which doesn't really give much useful information.

[GreyGeek]

Greygeek, I do have the snapshots, but didn't mention the name I gave them. Which brings me to a point: you identify the snapshots by date--is that required, or just good common sense? I just used @snapshot1, which doesn't really give much useful information.

Btrfs doesn't care, so the name you use is up to you. I rarely make more than one set snapshots on a given day, so just using YYYYMMDD gives me all the granularity I need. IF I were going to frequently make more than one set per day I'd use YYYYMMDDHHMM.

Sometimes, knowing that I am going to do some experimenting, I'll use @before_some_exp & @homebefore_some_exp. If, after some testing or things continue to work well after a period of time, I'll delete those two snapshots and create a dated pair.

[oshunluvr]

Greygeek, I do have the snapshots, but didn't mention the name I gave them. Which brings me to a point: you identify the snapshots by date--is that required, or just good common sense? I just used @snapshot1, which doesn't really give much useful information.

One caveat here: A snapshot will retain the date of the subvolume that was snapshot-ed. If you have your btrfs filesystem mounted with "nodirtime" (like some folks do with SSDs to reduce activity), the date of the subvolume snapshot itself will not be the date you took the snapshot - it will be the date of the source subvolume. You can manually invoke a date change by issuing a "touch" command to the snapshot after it is created. This will give the snapshot the current date/time.

Otherwise, I suggest using the date/time in your snapshot name. Adding this to your snapshot name will give you _YYMMDD_HHMMSS:

_`date +%y%m%d_%H%M%S`

So a snapshot of "@" called "@_`date +%y%m%d_%H%M%S` would look like

@_180611_124234

[GreyGeek]

My caveat is that when I make my first snapshot, on any particular day, I always create the @ snapshot first by doing
btrfs su snapshot -r /mnt/@ /mnt/snapshots/@20180611
sync
When the cursor comes back, usually within a second, I use the up arrow to recall that command, and the left arrow to get behind the "mnt/@", where I add "home" and then right arrow to "@20180611" and insert "home" between "@" and "20180611", then I hit the end key and then the Enter key.
Then
sync
and that's it.

I'm probably going to write a small script to do that ... someday, but I'd leave off the "_%H%M%S" part because I want my matched pair of snapshots to have the same date extension so they will be easier to manipulate using a maintenance script I may write ... in the future.

[oshunluvr]

My caveat is that when I make my first snapshot, on any particular day, I always create the @ snapshot first by doing
btrfs su snapshot -r /mnt/@ /mnt/snapshots/@20180611
sync
When the cursor comes back, usually within a second, I use the up arrow to recall that command, and the left arrow to get behind the "mnt/@", where I add "home" and then right arrow to "@20180611" and insert "home" between "@" and "20180611", then I hit the end key and then the Enter key.
Then
sync
and that's it.

I'm probably going to write a small script to do that ... someday, but I'd leave off the "_%H%M%S" part because I want my matched pair of snapshots to have the same date extension so they will be easier to manipulate using a maintenance script I may write ... in the future.

That's basically what I did. When I scripted mine, I eventually dropped the date/time from the snapshot name and went sequential with the names but added the "touch" command to provide an easy date/time reference.

[Casparov]

Vinny... This reply is not relevant to this post, but I had to register and track you down to thank you, SO MUCH, for saving me incalculable frustration in restoring my BEAUTIFUL Kubuntu 18.04 desktop via your fix found here: https://www.kubuntuforums.net/showth...zes-on-startup

I was weeks trying to fix it and had nearly given up... NOBODY ELSE COULD DO IT!!!!!! THANK-YOU!!!!!

[Casparov]

Vinny... This reply is not relevant to this post, but I had to register and track you down to thank you, SO MUCH, for saving me incalculable frustration in restoring my BEAUTIFUL Kubuntu 18.04 desktop via your fix found here: https://www.kubuntuforums.net/showth...zes-on-startup

I was weeks trying to fix it and had nearly given up... NOBODY ELSE COULD DO IT!!!!!! THANK-YOU!!!!!