On Fri, 18 Mar 2022 at 13:43, R. G. Newbury <newbury@mandamus.org> wrote:

On 2022-03-18 7:42 a.m., Angelo Moreschini wrote:
> I would like to ask for help about to choose the pertizioni to leave and
> those to format .. starting from the current situation that I transcribe
> below:

As outlined a new install will re-format *everything* as a Fedora
install over an existing setup will re-format the '/' and everything
contained in it. You have only the '/' partition as /dev/sdb3.

Fedora on needs to re-format the '/' and '/var' folders if you have
partitioned any other folders onto their own partitions. The other
partitions can be preserved across the install.

So, provided you have created a separate *partition* for /home or (for
example) /usr/local/sbin, you can do a 'bare-metal' type install of the
OS *without* disturbing those partitions. All of your data can carry
over to the new install without problem. Note that those partitions do
not need to be btrfs OR lvm. I am not sure why you are using lvm in this
case, as there is only one drive being used for Fedora.

I am not sure if the live-install version of Fedora includes gparted. If
not you can use sfdisk which I am sure is available on the live-install.
But since your objective is to re-format things, the easiest route would
just be to do an install which re-formats /dev/sdb3, then using that
install with gparted, create partitions for the new separate folders you
want, and re-install with that in place.

I would suggest that after /dev/sdb1 and /dev/sdb2, which are
efi-required that you set up partitions for '/', '/home', '/usr/local',
and 'var', plus any other separate partitions which you might want to
segregate (or back up separately, such as any business related
data/code/documents etc.) (Anything after '/' will be in an extended
partition)

Along with /home I use a separate /misc partition, which has all the
business-related stuff, the mysql databases, and web-site backup/local
runtime, so none of this needs to be re-installed or even touched on a
re-install. But it is easier to back up.

I managed *NIX systems for 35 years in a group working with data sets

much larger than filesystems until recently, which meant that filesystems

were repeatedly filled and emptied. Legacy *NIX filesystems degraded

when nearly full due to excessive fragmentation. Not only was that slow,

it was very hard on spinning disks, so many systems had measures to

prevent users from adding data past 85 to 90% of the capacity..

SSD's are a different story. Fragmentation has little impact on performance.

The memory used in SSD's does however, have a limited number of write

cycles before failing. Wear-leveling algorithms move blocks that show high

numbers of write cycles to prolong the period for which the full capacity is

available. I assume wear leveling is done at the lowest level and ignores

partitions and filesystems, but choices of filesystem and partitions can

have an impact on wear patterns and potential conflicts with wear-leveling.

Fixed partitions invariably end up with different fractions of free space.

With llvm you could reserve some space and use it to top up a partition

that was running out of space, but once the extra space has been used

you can be left with one full partition while another partition has ample

free space.

Fedora 35 default filesystem is btrfs. Btrfs makes a pool of the space not

needed for other filesystems, and then creates virtual partitions each the

size of the entire pool. The virtual partitions can grow as needed until

the pool is exhausted. This should simplify the wear-leveling workload,

so may prolong the useful life of SSD's,

I also have a 5G '/usr/local' which has my 'personal' executables, such
as games (FlightGear), and the mythtv setup. This partition also gets
the java /ice-tea libraries, and calibre.

/var is given its own partition as it gets over-written on a re-install
(even then, with mysql/mariadb on a different partition (misc) you need
only create a link for '/var/lib/mysql pointing to /misc/mysql to be up
and running.

So basically it is a matter of planning for what you know must happen,
and protecting what you what to be untouched in a separate partition.

Or just letting btrfs create over-sized "virtual partitions" and then allocating

physical space as needed.

With either strategy you still need backups of critical data.

George N. White III