it appears that there's ~16GB of available space in other filesystems
Well, if this available space was on disk(s), there might be a way to do what you want; but
tmpfs store data in RAM. RAM is volatile, you cannot use it for long-term storage.
Even if you could, these
3.9G values do not add. Ram-based filesystems take from a common pool. Adding files to one of them would reduce the space available to others.
In your case there are few layers of abstraction. Let's name them (outer first):
- the physical device
- partitions, among them the one used by LVM:
- the virtual device provided by LVM:
Changes in each layer are made with different actions/commands. In general, if you want to expand a filesystem and it requires few layers to be modified, you start from the most outer one; if you want to shrink, you start from the most inner, the filesystem itself.
So what is available for you? Your
52428800 sectors of
512 bytes. The sectors are numbered from
52428799. Among them:
- The sector
0 is MBR.
2047 probably hold (a part of) your bootloader. You shouldn't touch them. It's about 1 MiB anyway, not a significant space.
52426751 are your two partitions. We will go back to them in a moment.
52428799 are probably unused. Another 1 MiB, almost nothing.
fdisk -l and
lsblk to see if there are other devices available. This is a general advice, I guess if they were there you would know.
OK, how about
pvscan told you the whole space is distributed. The vast majority of it builds
/dev/mapper/fedora-root which holds your root filesystem (mounted under
/). The size of the filesystem is about 22 GiB. This is less than 24 GiB reported by
pvscan; possible reasons:
- LVM holds your swap partition, about 2 GiB (likely, run
swapon to confirm);
- or the filesystem is smaller than the
/dev/mapper/fedora-root virtual device (unlikely);
- other (unlikely).
/dev/sda1? It holds the filesystem mounted under
/boot. Most likely you don't need the whole 1 GiB for it, it could be smaller. If you shrink it, you will be able to create a new partition (like
sda3), add it to LVM and expand the root filesystem. If you shrink it too much, you will encounter problems during the OS upgrade. You probably could get couple of hundreds MiB out of it and avoid future problems anyway, but
- it's only few hundreds MiB;
- if anything goes wrong, your OS may not boot.
Your options (summary)
ncdu or similar tool to identify large files/directories in the root filesystem; think, investigate if you can delete them. This way maybe you can gain some free space without resizing the filesystem.
- Reduce the swap partition (if any) and reconfigure your LVM to be able to expand the root filesystem eventually. You haven't told us about your swap, it's hard to say how much you can gain or if there is any sense in it in the first place. In general you do need some amount of swap space.
- Shrink the filesystem currently mounted as
/boot (discussed above).
- Physically attach another device (like
/dev/sdb) and add it or its partition(s) to LVM. The information you provided makes me believe this is the only way to significantly increase your root filesystem. If it's a virtual machine we're talking about, you may be able to expand the existing device
/dev/sda (not usually possible for truly physical device) instead of adding a separate new one.
- It's good you're using LVM. It makes most of the above options simpler.
- Expanding the filesystem itself will be the last step. I don't know what type it is. Some filesystem types (ext4, btrfs) support on-line manipulation; this means you can expand a filesystem when it's mounted, very useful for a root filesystem.
- To guide you in more detail (actual commands etc.) we need to know what option you choose. Covering them all would make the question and answer(s) very broad, you would also need to provide a lot of additional information. Therefore
- (meta note) I suggest to let this question be "what ways of increasing root disk space do I have?" After you make your decision, you can ask another question for details (or maybe there is a similar question already). We can link from here to the detailed question later.