On Sun, Jan 26, 2025 at 1:15 PM Dale <rdalek1967@gmail.com> wrote:

Still, given the large
file systems in use, where should I draw the line and remain safe data
wise? Can I go to 90% if needed? 95%? Is that to much despite the
large amount of space remaining? Does the percentage really matter? Is
it more about having enough space for the file system to handle its
internal needs? Is for example 1 or 2TBs of free space enough for the
file system to work just fine?

It really depends on the filesystem. For ext4 you can go all the way
to zero bytes free with no issues, other than application issues from
being unable to create files. (If you're talking about the root
filesystem, then the "application" includes the OS so that isn't
ideal.)

Some filesystems don't handle running out of space well. These are
usually filesystems that handle redundancy internally, but you really
need to look into the specifics. Are you running something other than
ext4 here?

The space free almost always takes into account filesystem overhead.
The issue is generally whether the filesystem can actually free up
space once it runs out completely (COW might want to allocate space
just to delete things, due to the need to not overwrite metadata in
place).

--
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Feb 1, 2025 at 7:15 PM Dale <rdalek1967@gmail.com> wrote:

My thinking, even if I went to 95%, it should be OK given my usage. It
might even be OK at 99%. Thing is, I know at some point, something is
going to happen. I just been wondering what that point is and what it
will do. Oh, I do use ext4.

If you're using ext4 and this is a dedicated filesystem that no
critical applications need to be able to write to, then there really
are no bad consequences for filling the entire disk. With ext4 if you
want to get the same back you just need to rm some file. Really the
only downside for you in this use case is not being able to cram
something onto it when you want to.

Now, if you were running btrfs or cephfs or some other exotic
filesystems, then it would be a whole different matter, as those
struggle to recover space when they get too full. Something like ceph
also trades free space for failover space if you lose a disk, so if
you want the cluster to self-heal you need free space for it to work
with (and you want it to still be 85% free or so even after losing a
disk),

--
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Feb 1, 2025 at 8:40 PM Dale <rdalek1967@gmail.com> wrote:

Rich Freeman wrote:

Now, if you were running btrfs or cephfs or some other exotic
filesystems, then it would be a whole different matter,

I could see
some RAID systems having issues but not some of the more advanced file systems that are designed to handle large amounts of data.

Those are "RAID-like" systems, which is part of why they struggle when
full. Unlike traditional RAID they also don't require identical
drives for replication, which can also make it tricky when they start
to get full and finding blocks that meet the replication requirements
is difficult.

With a COW approach like btrfs you also have the issue that altering
the metadata requires free space. To delete a file you first write
new metadata that deallocates the space for the file, then you update
the pointers to make it part of the disk metadata. Since the metadata
is stored in a tree, updating a leaf node requires modifying all of
its parents up to the root, which requires making new copies of them.
It isn't until the entire branch of the tree is copied that you can
delete the old version of it. The advantage of this approach is that
it is very safe, and accomplishes the equivalent of full data
journaling without actually having to make more than one write of
things. If that operation is aborted the tree just points at the old
metadata and the in-progress copies are inside of free space, ignored
by the filesystem, and thus they just get overwritten the next time
the operation is attempted.

For something like ceph it isn't really much of a downside since this
it is intended to be professionally managed. For something like btrfs
it seems like more of an issue as it was intended to be a
general-purpose filesystem for desktops/etc, and so it would be
desirable to make it less likely to break when it runs low on space.
However, that's just one of many ways to break btrfs, so... :)

In any case, running out of space is one of those things that becomes
more of an issue the more complicated the metadata gets. For
something simple like ext4 that just overwrites stuff in place by
default it isn't a big deal at all.

--
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday 2 February 2025 02:07:07 Greenwich Mean Time Rich Freeman wrote:

On Sat, Feb 1, 2025 at 8:40 PM Dale <rdalek1967@gmail.com> wrote:

Rich Freeman wrote:

Now, if you were running btrfs or cephfs or some other exotic filesystems, then it would be a whole different matter,

I could see
some RAID systems having issues but not some of the more advanced file systems that are designed to handle large amounts of data.

Those are "RAID-like" systems, which is part of why they struggle when
full. Unlike traditional RAID they also don't require identical
drives for replication, which can also make it tricky when they start
to get full and finding blocks that meet the replication requirements
is difficult.

With a COW approach like btrfs you also have the issue that altering
the metadata requires free space. To delete a file you first write
new metadata that deallocates the space for the file, then you update
the pointers to make it part of the disk metadata. Since the metadata
is stored in a tree, updating a leaf node requires modifying all of
its parents up to the root, which requires making new copies of them.
It isn't until the entire branch of the tree is copied that you can
delete the old version of it. The advantage of this approach is that
it is very safe, and accomplishes the equivalent of full data
journaling without actually having to make more than one write of
things. If that operation is aborted the tree just points at the old metadata and the in-progress copies are inside of free space, ignored
by the filesystem, and thus they just get overwritten the next time
the operation is attempted.

For something like ceph it isn't really much of a downside since this
it is intended to be professionally managed. For something like btrfs
it seems like more of an issue as it was intended to be a
general-purpose filesystem for desktops/etc, and so it would be
desirable to make it less likely to break when it runs low on space.
However, that's just one of many ways to break btrfs, so... :)

In any case, running out of space is one of those things that becomes
more of an issue the more complicated the metadata gets. For
something simple like ext4 that just overwrites stuff in place by
default it isn't a big deal at all.

I've had /var/cache/distfiles on ext4 filling up more than a dozen times, because I forgot to run eclean-dist and didn't get a chance to tweak partitions to accommodate a larger fs in time. Similarly, I've also had / on ext4 filling up on a number of occasions over the years. Both of my ext4 filesystems mentioned above were created with default options. Hence -m, the reserved blocks % for the OS, would have been 5%. I cannot recall ever losing data or ending up with a corrupted fs. Removing some file(s) to create empty space allowed the file which didn't fit before to be written successfully and that was that. Resuming whatever process was stopped (typically emerge) allowed it to complete.

I also had smaller single btrfs partitions binding up a couple of times. I didn't lose any data, but then again these were stand alone filesystems not part of some ill advised buggy btrfs RAID5 configuration.

I don't deal with data volumes of the size Dale is playing with, so I can't comment on suitability of different filesystems for such a use case.


-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmefUD0ACgkQseqq9sKV ZxmyphAAz+k6UQ5w2t1ew04/WBU5mNznUwAuobJZ/vo9I8edNl3RB+Qf4KT7SFD1 WpvgmXEsP/jYQDqQJ/V19Nqtx+blbzvm7S692sRPf5B7w9Rz1kOPbMH6s+MeMufj 05dW8QcIauOMTa4mteNk5hps9Z5Jl7P6Q5es6DThzFdUKpAEQO+kHSnvuiFTjWte GNqedkuEHT76HQ7Z6K9bEl+v90Z3C2Ntgeou9gy5TdhZkW9YvuO/rsGqWshr8Fuj j8LM0unCgyh7ZkBBcgbx1ZxpcwKDsVYMlgEeDVH66f/E9484GtPCI/mSW8oUD+wY uJK0QFVN1DeV7YKJWVw34uU6NXx26SxOaV0THUHHIIobonq+fOh/IYh4YCrHf4sR ygYIMdEsQCIR1A4oGXWP9mhRlMP6VdLfaC+r0PfL76S6YxQRD605QdpAOZl1QFX2 KxuzOr/9Mm/JXXa4NFTvmmEmugPgqylY+tEC5D9PzAxIa3OJPDyaWoF0Sb6O7Zzr 1+B1wlG38AwD+IbSMTfi2b0X/G4KjbLiN58I6MSKW44mPigUzt0kYqq/Ly+m2+t+ vL3ZiabCwS3l/81D3/XxEQoOgO15xRmxEjGghCOQBmprvB44C1H/lnkkV3k78Si9 kAcWifXtTgSn02jpirmx5D6XQGG4Ft+TPcowTwqol2sfunPFJlk=
=W3L3
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)