I can't into lvm.

>>60411016
I have no clue about that SuSe GUI thing and your screenshot tells me nothing interesting, but I'll try anyhow.

> Of course I have no idea which physical volume contains how much of those 10 GB of data.
Aren't you putting this on your "Home" LV, which is a combination of PVs sdc and sdd?

At least it seemed to me like you were calling these "Home", so it'd make sense you'd have /home on them.

> Now, since the 10 GB would fit well on a single physical drive... What if I decide to use sdd for something else? Which is the way to go if I want to move (reduce) the entire logical volume to sdc?
Create a new LV in as of yet unallocated space, copy files over, delete the old volume.

>>60411151
I was afraid you'd say that. I hoped there would be a way to change the config on-the-fly.

>>60411209
You can do a lot of things. For instance, you could easily add a new drive with sufficient capacity, then pvmove and vgreduce so you can remove, say, sdd.

What you can't do is shrink XFS (or quite many other filesystems) directly.

Even those that support it usually give you a warning to first prepare a backup, because usually it's a quite unsafe operation given that the filesystem utilities might not even be able to recover all data possible in case of some failure occurring.

Basically, not worth doing in general. You pretty much always want to clone and restore. Can be easily done with rsync, xfsdump/xfsrestore or even cp / mv if you must.

>>60411016
1, If you only use the disk for data (i.e. you don't boot from it) and it's exclusively used by Linux, don't create partitions. You can make a PV straight from the raw disk and you have one less layer of bullshit to worry about.

2, pvmove moves all physical extents from one PV to another, all of that online so you won't even have to unmount the filesystem.

3, You can't shrink xfs at all. What you can do is dump the filesystem and restore it to a smaller LV/partition/whatever (if the size of data isn't larger than the LV you restore it to). Consult xfs documentation.

4, https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Logical_Volume_Manager_Administration/index.html
It's written for RHEL, but LVM is identical across all distros so all the command line tools will work on openSUSE as well.

>>60411539
>>60411584

Ok thanks, that sounds more like what I want to do. I guess I need to read some more on that topic before I switch to Linux on my main desktop. It gets kind of confusing when you come from Windows.

>>60411693
Some more things:

ext4 is better for LVM because you can shrink it when it's offline (unmounted).

You almost certainly don't need a separate /opt.
What you should have is separate /var and /tmp. /var contains variable data and logs and a runaway program can fill it rather quickly, so keeping it separate can save the rest of the filesystem. Same for /tmp. I'd suggest a maximum of 5 GB for each of them. Even that may be wasteful, but whatever. Diskspace is cheap these days.

>>60412014
Well, thanks for the advice. I'll keep that in mind.

You see, I have a 120 GB SSD which I want to use as sda for the system itself, another 250 GB SSD I thought could be useful for optional software (hypervisors and my VMs or maybe even games on Steam), so they would start quickly when I run them.

Home will go on my 1 TB HDD, of course. The thought behind 2 physical drives for 1 logical home volume was in case I want to move my stuff around quickly or even replace any of the disks by a bigger one entirely. I have a lot of stuff on my Windows machine.

>>60412317
Maybe it would be smart to put /var and /tmp on the 1 TB HDD alongside /home?

>>60412317
/opt is mostly used by commercial software or when you manually compile software of several different versions.
Most of the software installed by the package manager gets installed into the /usr hierarchy. The 120 GB SSD is enough for that and you should keep it as a part of /.

Steam is a really shitty port of a Windows application to Linux. When you install Steam from the package manager, it installs a small Steam installer that downloads the proper Steam into a hidden .steam directory in the home of user that runs it. Games install into this hidden directory by default. Really shitty, I know. What you can do is make a new steam games library somewhere else - you can find it somewhere in Steam options. You can then select where each game installs.

I can suggest you my setup since it's pretty similar:
I have a 120 GB SSD that contains a VG with LVs for /, /home, and /var. (/tmp is mounted from RAM since I have 16 GB)
I have an old 250 GB HDD with only a single XFS filesystem (no partitions or LVM) that is mounted on /depot (created by me) that contains a directory with steam library and another one where I put VM disk images.

Alternatively, you can make a VG on the 250 GB disk and create an LV with filesystem for the steam library and then create an LV without filesystem for each virtual machine and pass them to the VMs as raw disks. That should speed up I/O a bit since the hypervisor doesn't have to worry about filesystem.

>>60413117
Sounds good. I really like the idea of providing raw disks since I will do a lot of virtualization. I will give it a try.