10:17 a.m.
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
10:39 a.m.
Am 06.02.2022 um 17:17 schrieb Paolo Galtieri
<pgaltieri(a)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)?
10:42 a.m.
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.
--
Garry T. Williams
10:49 a.m.
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 ...
--
francis
11:26 a.m.
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(a)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 ...
4:48 p.m.
Am 06.02.2022 um 18:26 schrieb Paolo Galtieri
<pgaltieri(a)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
5 p.m.
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.
4:18 a.m.
Am 07.02.2022 um 00:00 schrieb Samuel Sieb <samuel(a)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.
3:43 a.m.
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
4:26 a.m.
Am 07.02.2022 um 10:43 schrieb GianPiero Puccioni
<gianpiero.puccioni(a)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.
1:50 p.m.
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.o...
2 p.m.
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.
4:12 p.m.
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.o...
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.
{+_+}
6:06 p.m.
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
6:34 p.m.
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.
12:18 a.m.
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).
--
uname -rsvp
Linux 3.10.0-1160.53.1.el7.x86_64 #1 SMP Fri Jan 14 13:59:45 UTC 2022 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
7:30 a.m.
Am 08.02.2022 um 12:11 schrieb Patrick O'Callaghan
<pocallaghan(a)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
8:34 p.m.
On Tue, Feb 8, 2022 at 6:30 AM Peter Boy <pboy(a)uni-bremen.de> wrote:
> Am 08.02.2022 um 12:11 schrieb Patrick O'Callaghan
<pocallaghan(a)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/Ins...
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/Ins...
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
4:35 p.m.
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.o...
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
6:56 a.m.
Am 07.02.2022 um 23:35 schrieb Patrick O'Callaghan
<pocallaghan(a)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.o...
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
8:03 a.m.
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
4:15 p.m.
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....
5:45 p.m.
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
7:28 p.m.
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.
8:08 p.m.
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.
859
days inactive
862
days old
27 comments
15 participants
participants (15)
-
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