Folks, today I ran into a strange problem. Both the root file system and the /home filesystem showed 100% usage:
df -l Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 4096 0 4096 0% /dev tmpfs 32793004 0 32793004 0% /dev/shm tmpfs 13117204 2512 13114692 1% /run /dev/nvme0n1p10 283625472 281920988 735540 100% / tmpfs 32793008 11612 32781396 1% /tmp /dev/nvme0n1p10 283625472 281920988 735540 100% /home /dev/nvme0n1p8 463826 258874 176485 60% /boot /dev/nvme0n1p7 487160 14280 472880 3% /boot/efi tmpfs 6558600 196 6558404 1% /run/user/1000 tmpfs 6558600 88 6558512 1% /run/user/0
When I did a du -s of my home directory it showed only 96GB used.
sudo du -s /home/*
96910360 /home/pgaltieri
The problem turned out to be a large file in /usr/local. When I removed this file both / and /home dropped in their usage:
Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 4096 0 4096 0% /dev tmpfs 32793004 0 32793004 0% /dev/shm tmpfs 13117204 2616 13114588 1% /run */dev/nvme0n1p10* 283625472 187104116 95417980 67% / tmpfs 32793008 11860 32781148 1% /tmp */dev/nvme0n1p10* 283625472 187104116 95417980 67% /home /dev/nvme0n1p8 463826 258874 176485 60% /boot /dev/nvme0n1p7 487160 14280 472880 3% /boot/efi tmpfs 6558600 204 6558396 1% /run/user/1000
so why are / and /home the same device? In the past / and /home where separate devices. This is for F31
Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 8121488 0 8121488 0% /dev tmpfs 8142632 97596 8045036 2% /dev/shm tmpfs 8142632 2000 8140632 1% /run */dev/mapper/fedora-root* 51475068 36099716 12737528 74% / tmpfs 8142632 171148 7971484 3% /tmp */dev/mapper/fedora-home* 645292064 391044160 221445908 64% /home /dev/sda8 487652 203435 254521 45% /boot /dev/sda1 507904 61176 446728 13% /boot/efi
Paolo
Am 06.02.2022 um 17:17 schrieb Paolo Galtieri pgaltieri@gmail.com:
Folks, today I ran into a strange problem. Both the root file system and the /home filesystem showed 100% usage:
df -l Filesystem 1K-blocks Used Available Use% Mounted on ... /dev/nvme0n1p10 283625472 281920988 735540 100% / ... /dev/nvme0n1p10 283625472 281920988 735540 100% /home
as you may notice / and /home use the same disk area. Are you on aarch64? And do you use btrfs file system (look at the output of e.g. mount)?
On Sunday, February 6, 2022 11:17:25 AM EST Paolo Galtieri wrote:
so why are / and /home the same device? In the past / and /home where separate devices.
You probably have / and /home on subvolumes of a btrfs file system. That is the current default configuration now.
Hi.
On Sun, 06 Feb 2022 11:42:22 -0500 "Garry T. Williams" wrote:
You probably have / and /home on subvolumes of a btrfs file system.
+1
The clearer way to see that is probably to use:
findmnt --notruncate / findmnt --notruncate /home
Example: see the subvol= option:
findmnt --notruncate / TARGET SOURCE FSTYPE OPTIONS / /dev/mapper/luks-c92191d5-7811-49f9-867c-1e300d1e9410[/root] btrfs rw,relatime,compress=lzo,ssd,space_cache,subvolid=258,subvol=/root
findmnt --notruncate /home TARGET SOURCE FSTYPE OPTIONS /home /dev/mapper/luks-c92191d5-7811-49f9-867c-1e300d1e9410[/home] btrfs rw,relatime,compress=lzo,ssd,space_cache,subvolid=257,subvol=/home
That is the current default configuration now.
But it was not in F31 ...
The system is x86_64 and I'm using brtfs. So that clears that up:
findmnt --notruncate /
TARGET SOURCE FSTYPE OPTIONS / /dev/nvme0n1p10[/root00] btrfs rw,relatime,seclabel,ssd,space_cache,subvolid=276,subvol=/root00
findmnt --notruncate /home
TARGET SOURCE FSTYPE OPTIONS /home /dev/nvme0n1p10[/home] btrfs rw,relatime,seclabel,ssd,space_cache,subvolid=257,subvol=/home
However, it's still confusing to me having df show that both /home and / are filled up when du -s shows that /home is only using 96G. I found the problem by doing du -s /usr/* and saw that /usr/local was consuming a lot of space.
du -s /home 96971060 /home
du -s / 5436965761 /
Paolo
On 2/6/22 08:49, Francis.Montagnac@inria.fr wrote:
Hi.
On Sun, 06 Feb 2022 11:42:22 -0500 "Garry T. Williams" wrote:
You probably have / and /home on subvolumes of a btrfs file system.
+1
The clearer way to see that is probably to use:
findmnt --notruncate / findmnt --notruncate /home
Example: see the subvol= option:
findmnt --notruncate / TARGET SOURCE FSTYPE OPTIONS / /dev/mapper/luks-c92191d5-7811-49f9-867c-1e300d1e9410[/root] btrfs rw,relatime,compress=lzo,ssd,space_cache,subvolid=258,subvol=/root
findmnt --notruncate /home TARGET SOURCE FSTYPE OPTIONS /home /dev/mapper/luks-c92191d5-7811-49f9-867c-1e300d1e9410[/home] btrfs rw,relatime,compress=lzo,ssd,space_cache,subvolid=257,subvol=/home
That is the current default configuration now.
But it was not in F31 ...
Am 06.02.2022 um 18:26 schrieb Paolo Galtieri pgaltieri@gmail.com:
The system is x86_64 and I'm using brtfs. So that clears that up:
findmnt --notruncate /
TARGET SOURCE FSTYPE OPTIONS / /dev/nvme0n1p10[/root00] btrfs rw,relatime,seclabel,ssd,space_cache,subvolid=276,subvol=/root00
findmnt --notruncate /home
TARGET SOURCE FSTYPE OPTIONS /home /dev/nvme0n1p10[/home] btrfs rw,relatime,seclabel,ssd,space_cache,subvolid=257,subvol=/home
However, it's still confusing to me having df show that both /home and / are filled up when du -s shows that /home is only using 96G. I found the problem by doing du -s /usr/* and saw that /usr/local was consuming a lot of space.
BTRFS subvolumes are not dedicated volumes as you may have used to in Fedora 31. That version used xfs filesystem, where every volume is a separate space, not entangeled with any other volume.
With version 33 Fedora workstation switched to btrfs. Here subvolumes are no longer dedicated separate entities, but just a kind of groups of files tagged the same label, „home“ or „/„. But they share the same real total disk space. „In real“ you have only one large partition, where you can define „tags“, called subvolume, which gather a bunch of files under the same label.
So, the output of df may be a bit misleading. The row „available“ refers not the the subvolume, but to the total space left for both of your subvolumes. That is a big difference to Fedora 31 you’re used to.
There are cons and pros, as with any technical features. One of the pros is you can group files without having to reserve a fixed storage area in advance. But still you can do "group activities“ (= subvolume operations), e.g. backup and restore just /home without touching system files.
Among the cons is, as your /home grows it minimizes the space for „/„. So it can completely block your system (this could not happen with F31 and xfs.) But you can take other group activities, e.g. limit the maximum space for the group /home (=subvolume /home), so that there is always enough space left for /.
If you do not want this behavior, you can choose the old xfs during the installation, among other things. Some people use the server DVD, which defaults to xfs and dedicated partitions, to install the system, and add a graphical interface.
But nevertheless, the good news is, there is nothing wrong with your system.
Best Peter
On 2/6/22 14:48, Peter Boy wrote:
BTRFS subvolumes are not dedicated volumes as you may have used to in Fedora 31. That version used xfs filesystem, where every volume is a separate space, not entangeled with any other volume.
Before btrfs, workstation used ext4 as the default. It was only server that switched to xfs.
On 06/02/2022 23:48, Peter Boy wrote: about using brtfs:
Among the cons is, as your /home grows it minimizes the space for „/„. So it can completely block your system (this could not happen with F31 and xfs.) But you can take other group activities, e.g. limit the maximum space for the group /home (=subvolume /home), so that there is always enough space left for /.
Another con is that it is really hard to reinstall without destroing /home. I'm not using brtfs again unless this is somehow corrected....
GiP
Am 07.02.2022 um 00:00 schrieb Samuel Sieb samuel@sieb.net:
On 2/6/22 14:48, Peter Boy wrote:
BTRFS subvolumes are not dedicated volumes as you may have used to in Fedora 31. That version used xfs filesystem, where every volume is a separate space, not entangeled with any other volume.
Before btrfs, workstation used ext4 as the default. It was only server that switched to xfs.
Thanks for the info. F31, "felt" it was a long time ago.
The basic characteristics regarding the original question are the same, though.
Am 07.02.2022 um 10:43 schrieb GianPiero Puccioni gianpiero.puccioni@isc.cnr.it:
On 06/02/2022 23:48, Peter Boy wrote: about using brtfs:
Among the cons is, as your /home grows it minimizes the space for „/„. So it can completely block your system (this could not happen with F31 and xfs.) But you can take other group activities, e.g. limit the maximum space for the group /home (=subvolume /home), so that there is always enough space left for /.
Another con is that it is really hard to reinstall without destroing /home. I'm not using brtfs again unless this is somehow corrected....
GiP
Agreed. And even worse, in case of a serious filesystem issue probably not only data of one subvolume are lost but of allsubvolumes. Well, hopefully a most rare event.
Those are some cons why the server WG could not get enthusiastic about btrfs.
On 2/6/22 08:17, Paolo Galtieri wrote:
so why are / and /home the same device?
To the question of "why," I'd think the answer is in the discussion held in the devel@ mailing list linked below. Generally, sharing the storage pool in order to avoid running out of space in one location when there was still space left in the pool due to "bad" partitioning choices was seen as a benefit.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
On Mon, 7 Feb 2022 11:50:12 -0800 Gordon Messmer wrote:
Generally, sharing the storage pool in order to avoid running out of space in one location when there was still space left in the pool due to "bad" partitioning choices was seen as a benefit.
Yep, I've been partitioning systems that way for years for that very reason. Does mean more places to look to find out why you are running out of space, but you don't run out of space anywhere quite as fast.
On 20220207 11:50:12, Gordon Messmer wrote:
On 2/6/22 08:17, Paolo Galtieri wrote:
so why are / and /home the same device?
To the question of "why," I'd think the answer is in the discussion held in the devel@ mailing list linked below. Generally, sharing the storage pool in order to avoid running out of space in one location when there was still space left in the pool due to "bad" partitioning choices was seen as a benefit.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Ah, fix it so that when the system logs run away you can also destroy user data that has not been written yet. Gooood planning. Why bother with defining a separate /home at all? It gives a false sense of security.
{+_+}
On Mon, 2022-02-07 at 11:50 -0800, Gordon Messmer wrote:
On 2/6/22 08:17, Paolo Galtieri wrote:
so why are / and /home the same device?
To the question of "why," I'd think the answer is in the discussion held in the devel@ mailing list linked below. Generally, sharing the storage pool in order to avoid running out of space in one location when there was still space left in the pool due to "bad" partitioning choices was seen as a benefit.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
From btrfs-quota(8):
On the other hand, the traditional approach has only a poor solution to restrict directories. At installation time, the harddisk can be partitioned so that every directory (eg. /usr, /var/, ...) that needs a limit gets its own partition. The obvious problem is that those limits cannot be changed without a reinstallation. The btrfs subvolume feature builds a bridge. Subvolumes correspond in many ways to partitions, as every subvolume looks like its own filesystem. With subvolume quota, it is now possible to restrict each subvolume like a partition, but keep the flexibility of quota. The space for each subvolume can be expanded or restricted on the fly.
poc
On 2022-02-07 5:39 p.m., Joe Zeff wrote:
On 2/7/22 15:12, jdow wrote:
Ah, fix it so that when the system logs run away you can also destroy user data that has not been written yet. Gooood planning. Why bother with defining a separate /home at all? It gives a false sense of security.
Only if you define it as btrfs.
Maybe its time to ask the stupid question: Why is not /var in its own subvolume, and why does it not have a quota by default? That would almost trivially resolve the issue of runaway logs making the system unusable.
--
John Mellor
On 2/7/22 14:12, jdow wrote:
Ah, fix it so that when the system logs run away you can also destroy user data that has not been written yet.
That's... not really how POSIX works. And most logs on Fedora should be in the journal at this point, has a maximum size.
Gooood planning. Why bother with defining a separate /home at all? It gives a false sense of security.
I don't see how there's any less "security" for /home now than there was before. It's not like the old system was immune from user processes "running away" and filling the filesystem. The system has never held space in reserve for non-root users.
There are a long list of good reasons to make /home a subvolume, though. It's groundwork for system snapshots that can be rolled back in the event of an update failure. It's easier to preserve /home but perform a clean install for everything else. Replication (possibly as a backup mechanism) requires subvolume as a boundary, and separating / and /home for that is desirable most of the time.
On Mon, 2022-02-07 at 14:12 -0800, jdow wrote:
Why bother with defining a separate /home at all? It gives a false sense of security.
There are various different reasons people do partitioning (whether that be home, boot, var, whatever). It's not all about security (or lack of).
You might want it completely separate (partition or different drive altogether) so that system updates can be done around /home without losing it. Of course you should have backups, but if you can keep /home during an update, that saves having to re-import it.
A 100% filled up home doesn't wedge the system.
You may actually want hard size limits on different partitions.
You may want different mounting options.
Historically, there was also that people chose partitions for speed optimisation (putting constantly accessed files into the fastest parts of the drive).
Am 07.02.2022 um 23:35 schrieb Patrick O'Callaghan pocallaghan@gmail.com:
On Mon, 2022-02-07 at 11:50 -0800, Gordon Messmer wrote:
On 2/6/22 08:17, Paolo Galtieri wrote:
so why are / and /home the same device?
To the question of "why," I'd think the answer is in the discussion held in the devel@ mailing list linked below. Generally, sharing the storage pool in order to avoid running out of space in one location when there was still space left in the pool due to "bad" partitioning choices was seen as a benefit.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
From btrfs-quota(8):
On the other hand, the traditional approach has only a poor solution to restrict directories. At installation time, the harddisk can be partitioned so that every directory (eg. /usr, /var/, ...) that needs a limit gets its own partition. The obvious problem is that those limits cannot be changed without a reinstallation. The btrfs subvolume feature builds a bridge. Subvolumes correspond in many ways to partitions, as every subvolume looks like its own filesystem. With subvolume quota, it is now possible to restrict each subvolume like a partition, but keep the flexibility of quota. The space for each subvolume can be expanded or restricted on the fly.
The quote describes a situation which has gone for more of a decade now. Since we have LVM (when got that part of the Linux kernel? kernel 2.6? 2004 or so? Don’t know exactly), no one would partition a hard disk along file system subdirectories. You create logical volumes instead, which can easily "changed without a reinstallation“ and space for any logical volume "can be expanded or restricted on the fly“. The latter even easier with „thin provisioning“. And of course you can do backups and restores via snapshot, it's called LVM snapshot. What a surprise.
And you can do all that without that "subvolume (only) looks like its own filesystem“ but in reality are not separate and independent filesystems but merely pretend to be.
BTRFS has specific advantages, without a doubt. And it is attractive for specific use cases. But it's not a silver bullet against all the tribulations of file storage, nor is it the only way to the future of IT. And by far it is not the almighty system, which fits everything as default, as many "BTRFS missionaries" would have you believe, throwing buzz words around.
Peter
Am 08.02.2022 um 12:11 schrieb Patrick O'Callaghan pocallaghan@gmail.com:
On Tue, 2022-02-08 at 16:48 +1030, Tim via users wrote:
You may actually want hard size limits on different partitions.
You can still have this with subvolumes. See btrfs-quota(8).
Yes, a sentence beginning with „You can have this with ….“ is probably true for every IT topic.
The question is rather whether you can realistically have it in everyday practice.
Workstation WG made BTRFS default with F33. Even now with F35 one year later, where is easily accessible documentation for a user who wants to install Workstation? Neither the current Installation Guide nor the Administrator's Guide give any information about how to handle BTFRS. The complete text is up to date with Fedora 25 or perhaps a bit later, only minimally updated to subsequent versions.
And I see no Workstation doc listet on docs.fp.o, unlike the other Fedora editions, again, after a year.
And is there an adapted installation step in Anaconda to expose an option to set a max. limit (e.g. like to handle the root login - deactivated, key only, . . .) and probably some other valuable capabilities? I can’t remember to have seen something like that.
Therefore, a user is dependent on clear and informative terminology. And, well, sub-„volume“ after 32 Fedora releases has a specific meaning.
(And that is one of my issues with those „missionaries“ who fight about their principles, but don’t care about their flock)
Peter
On Tue, 2022-02-08 at 13:56 +0100, Peter Boy wrote:
On the other hand, the traditional approach has only a poor solution to restrict directories. At installation time, the harddisk can be partitioned so that every directory (eg. /usr, /var/, ...) that needs a limit gets its own partition. The obvious problem is that those limits cannot be changed without a reinstallation. The btrfs subvolume feature builds a bridge. Subvolumes correspond in many ways to partitions, as every subvolume looks like its own filesystem. With subvolume quota, it is now possible to restrict each subvolume like a partition, but keep the flexibility of quota. The space for each subvolume can be expanded or restricted on the fly.
The quote describes a situation which has gone for more of a decade now. Since we have LVM (when got that part of the Linux kernel? kernel 2.6? 2004 or so? Don’t know exactly), no one would partition a hard disk along file system subdirectories. You create logical volumes instead, which can easily "changed without a reinstallation“ and space for any logical volume "can be expanded or restricted on the fly“. The latter even easier with „thin provisioning“. And of course you can do backups and restores via snapshot, it's called LVM snapshot. What a surprise.
I've been using BTRFS for several years now and it suits me. I could never get my head around LVM and considered it overkill for what most workstation users need, but that's a matter of personal taste.
poc
On 2/8/22 12:44, Joe Zeff wrote:
On 2/8/22 05:56, Peter Boy wrote:
no one would partition a hard disk along file system subdirectories.
Want to bet? Some of us, especially home users, consider LVM a pointless complication for our use case and never use it.
I am still using EXT4 partitions (via manual partition setup) for F35 on my notebook for /boot, /, and /home:
temp stuff deleted.
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 69G 27G 39G 42% / /dev/sda1 974M 293M 614M 33% /boot /dev/sda5 372G 241G 113G 69% /home
I've still got plenty of room on my 500GB SSD drive, so I am not concerned about space. Perhaps with F36 (or F37 if I skip), I will try and see if btrfs gains me anything for possible performance loss.
Oh, in /home/common/ietf I have ALL RFCs and drafts! (over 138K drafts!), so lots of little files....
On Tue, 2022-02-08 at 17:15 -0500, Robert Moskowitz wrote:
On 2/8/22 12:44, Joe Zeff wrote:
On 2/8/22 05:56, Peter Boy wrote:
no one would partition a hard disk along file system subdirectories.
Want to bet? Some of us, especially home users, consider LVM a pointless complication for our use case and never use it.
I am still using EXT4 partitions (via manual partition setup) for F35 on my notebook for /boot, /, and /home:
temp stuff deleted.
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 69G 27G 39G 42% / /dev/sda1 974M 293M 614M 33% /boot /dev/sda5 372G 241G 113G 69% /home
I've still got plenty of room on my 500GB SSD drive, so I am not concerned about space. Perhaps with F36 (or F37 if I skip), I will try and see if btrfs gains me anything for possible performance loss.
Oh, in /home/common/ietf I have ALL RFCs and drafts! (over 138K drafts!), so lots of little files....
I used to do the same, having to manually partition because the default setup was LVM. However I prefer BTRFS because a) I don't have to guess what size of partitions to create at install time, something which is difficult to change later, and b) BTRFS includes features such as snapshots and built-in RAID without having to deal with an additional layer as with LVM.
Again, it's a matter of preference.
poc
On 2/8/22 04:56, Peter Boy wrote:
The quote describes a situation which has gone for more of a decade now. Since we have LVM (when got that part of the Linux kernel? kernel 2.6? 2004 or so? Don’t know exactly), no one would partition a hard disk along file system subdirectories. You create logical volumes instead, which can easily "changed without a reinstallation“ and space for any logical volume "can be expanded or restricted on the fly“. The latter even easier with „thin provisioning“.
Expanded, sure. But restricted? I don't think that's as clear for LVM. IIRC, XFS can't be shrunk at all, and ext4 can only be shrunk offline. Users should be able to create, destroy, or resize qgroups online for btrfs.
I'm unclear on what you mean is easier with thin provisioning; can you clarify that?
I may be naive here, as I use writable snapshots in LVM but not thin provisioning specifically: my impression was that users needed to be very careful not to allow the volume group to run out of space when using either of these, because filesystems generally don't deal well with the unexpected write failures that occur when LVM has no more extents to allocate. btrfs' free space handling can be surprising to users, and statfs() might suggest there is more space available than there is, but it's not the sort of thing that can corrupt the filesystem itself.
On 2022-02-08 17:28, Gordon Messmer wrote:
On 2/8/22 04:56, Peter Boy wrote:
The quote describes a situation which has gone for more of a decade now. Since we have LVM (when got that part of the Linux kernel? kernel 2.6? 2004 or so? Don’t know exactly), no one would partition a hard disk along file system subdirectories. You create logical volumes instead, which can easily "changed without a reinstallation“ and space for any logical volume "can be expanded or restricted on the fly“. The latter even easier with „thin provisioning“.
Expanded, sure. But restricted? I don't think that's as clear for LVM. IIRC, XFS can't be shrunk at all, and ext4 can only be shrunk offline. Users should be able to create, destroy, or resize qgroups online for btrfs.
I'm unclear on what you mean is easier with thin provisioning; can you clarify that?
I may be naive here, as I use writable snapshots in LVM but not thin provisioning specifically: my impression was that users needed to be very careful not to allow the volume group to run out of space when using either of these, because filesystems generally don't deal well with the unexpected write failures that occur when LVM has no more extents to allocate. btrfs' free space handling can be surprising to users, and statfs() might suggest there is more space available than there is, but it's not the sort of thing that can corrupt the filesystem itself.
Exactly! I tried using thin provisioning once as a way to solve the "how much in / and how much in /home" dilemna and ended up regretting it. There is no indication of how much space is really available and when it ran out, it was messy. At least btrfs gives you an accurate number even if it might be a little confusing at first why / is getting so small when you fill up /home.
On Tue, Feb 8, 2022 at 6:30 AM Peter Boy pboy@uni-bremen.de wrote:
Am 08.02.2022 um 12:11 schrieb Patrick O'Callaghan pocallaghan@gmail.com:
On Tue, 2022-02-08 at 16:48 +1030, Tim via users wrote:
You may actually want hard size limits on different partitions.
You can still have this with subvolumes. See btrfs-quota(8).
Yes, a sentence beginning with „You can have this with ….“ is probably true for every IT topic.
The question is rather whether you can realistically have it in everyday practice.
Yes, (open)SUSE enables qgroups by default for years. Fedora doesn't enable them, but it's worth checking out 'man btrfs quota'. They're pretty cool, and the docs consider the dilemmas raised by snapshots, and how that affects accounting. There are some performance concerns. Desktop users don't need to worry about it, you can enable them, play, disable them. The whole quota btree is removed, no residue remains on the file system.
Workstation WG made BTRFS default with F33. Even now with F35 one year later, where is easily accessible documentation for a user who wants to install Workstation? Neither the current Installation Guide nor the Administrator's Guide give any information about how to handle BTFRS. The complete text is up to date with Fedora 25 or perhaps a bit later, only minimally updated to subsequent versions.
?
https://docs.fedoraproject.org/en-US/fedora/f35/install-guide/install/Instal...
Those are Fedora 33 screenshots. "btrfs" appears 34 times in the document. There's an entire section on creating a btrfs layout. https://docs.fedoraproject.org/en-US/fedora/f35/install-guide/install/Instal...
Since I wrote up the lightweight changes for docs when btrfs became the default, I'm aware that the documentation has weaknesses. It is still LVM centric, and doesn't have hints for Btrfs nuances.
In particular, with how to get the installer to reuse the "home" subvolume for the /home mountpoint. It is super easy to do, but totally non-obvious. The part most folks run into is not reusing "home" subvolume itself, which is just a matter of clicking on the previous installation "home" and assigning it to the /home mountpoint. But rather how to install to / because it won't let you reuse the "root" subvolume. This is due to the installer requiring a new clean filesystem for root. Ext4 and XFS require reformat, but Btrfs gets a partial exemption. You don't have to reformat, but you do need a new "root" subvolume, so you just create a new mountpoint with the + button, specify the mountpoint as /, and leave the capacity field blank. It'll add / mountpoint *and* create a new subvolume in the process. You can either delete the old "root" subvolume, or keep it - it's a matter of space available but as all subvolume share space it's a pretty simple calculation whether you have room for it or not.
And I see no Workstation doc listet on docs.fp.o, unlike the other Fedora editions, again, after a year.
1. https://docs.fedoraproject.org/en-US/docs/ 2. click on engineering teams, https://docs.fedoraproject.org/en-US/engineering/ 3. click on workstation working group, https://docs.fedoraproject.org/en-US/workstation-working-group/
And is there an adapted installation step in Anaconda to expose an option to set a max. limit (e.g. like to handle the root login - deactivated, key only, . . .) and probably some other valuable capabilities? I can’t remember to have seen something like that.
Workstation is a different installation experience than Server. Workstation does a Live install, using rsync, and users are setup in GNOME Initial Setup rather than in the installer.
Therefore, a user is dependent on clear and informative terminology. And, well, sub-„volume“ after 32 Fedora releases has a specific meaning.
There are only so many words.
I'm reminded of the word "chunk". You see this word quite a bit in computer storage. If you specialize in one thing or another, you might get the idea that chunk is a specialized word that has a pretty specific meaning. And then you're surprised when you come across that same term in another context, it means something quite different. Chunk in mdadm is what the SNIA dictionary calls "strip" or "stripe element" [1] On Btrfs, chunk is a different thing entirely, there's no SNIA equivalent term. So it's certainly easy to get confused when terms get reused.
[1] can you believe those two terms are synonyms?[2] [2] part of the problem might be the English language, really. If you've ever been confused about strip and stripe [3], it's not you, it's the words themselves. [3] These two terms are not synonyms. [4] [4] It really could make you a bit bonkers. I've really digressed now.
-
Chris Murphy -
Francis.Montagnac＠inria.fr -
Garry T. Williams -
GianPiero Puccioni -
Gordon Messmer -
jdow -
Joe Zeff -
John Mellor -
Paolo Galtieri -
Patrick O'Callaghan -
Peter Boy -
Robert Moskowitz -
Samuel Sieb -
Tim -
Tom Horsley