I am just starting to get into the UEFI with my newer computer. I notice that f38's auto partitioning creates a partition and formats it with xfs. I suppose manually ext4 could be used. This drive I don't believe is too big for ext4. But it would take a little time to format.
My question is, using manual or "custom" partitioning would I want a 250-500 MB partition with the ID 0xef00 and then an ext4 partition, for use with linux? I know M$ adds all kinds of additions to the UEFI spec. What is needed for linux in making a custom partition set up?
Bill
On 9/14/23 18:15, Bill Cunningham wrote:
I am just starting to get into the UEFI with my newer computer. I notice that f38's auto partitioning creates a partition and formats it with xfs. I suppose manually ext4 could be used. This drive I don't believe is too big for ext4. But it would take a little time to format.
You must be using the server edition, because otherwise the default is btrfs which I recommend.
My question is, using manual or "custom" partitioning would I want a 250-500 MB partition with the ID 0xef00 and then an ext4 partition, for use with linux? I know M$ adds all kinds of additions to the UEFI spec. What is needed for linux in making a custom partition set up?
You need an EFI partition and probably an ext4 /boot partition if you're formatting the rest as btrfs.
Bill Cunningham composed on 2023-09-14 21:15 (UTC-0400):
I am just starting to get into the UEFI with my newer computer. I notice that f38's auto partitioning creates a partition and formats it with xfs. I suppose manually ext4 could be used. This drive I don't believe is too big for ext4. But it would take a little time to format.
My question is, using manual or "custom" partitioning would I want a 250-500 MB partition with the ID 0xef00 and then an ext4 partition, for use with linux? I know M$ adds all kinds of additions to the UEFI spec. What is needed for linux in making a custom partition set up?
UEFI booting requires an ESP (Efi System Partition) whether you want one or not. :) As little as 1 file on it can get Linux booted. UEFI Windows/Linux multibooters get by fine with the original 100M ESP Windows creates by default, typically having far more freespace on the ESP than used.
Some people like mixing the OS with user data (only one EXT4 or BTRFS), or keeping it separate (at least 2 EXT4 or BTRFS). I always have my /home/ on a separate filesystem. The OS doesn't really need backing up once you get intimate with the installation process. It's easy enough to install afresh if the OS filesystem gets too messed up. I don't give the OS partition even 20G. Most I don't even give 10G, though all my installations are at least initially minimalist. Right now I'm running on 18G, 3 kernels are installed, and 75% is freespace.
Joe Zeff composed on 2023-09-14 20:49 (UTC-0600):
Felix Miata wrote:
I always have my/home/ on a separate filesystem.
My guess is it is an administrative thing. They probably get or think they get more and/or wilder complaints about mal-sizing separate filesystems than they do not making them separate. There's a BTRFS component to it too. BTRFS devs seem to think only one is somehow better due to its inclusion of LVM technology.
Am 15.09.2023 um 04:57 schrieb Felix Miata mrmazda@earthlink.net:
BTRFS devs seem to think only one is somehow better due to its inclusion of LVM technology.
There is no „inclusion of LVM technology“ in BTRFS. LVM provides you with several separate filesystems, completely independent from each other. A file system failure in one LVM volume does not affect any of the other volumes. All data in other volumes are safe. In BTRFS, everything is a single huge file system, (sub)volumes are just logical groupings within a single, in the worst case faulty, file system. The advantage of BTRFS is greater flexibility and effectiveness of disk capacity usage, at the expense of data protection.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
Peter Boy composed on 2023-09-15 08:56 (UTC+0200):
Felix Miata composed:
BTRFS devs seem to think only one is somehow better due to its inclusion of LVM technology.
There is no „inclusion of LVM technology“ in BTRFS. LVM provides you with several separate filesystems, completely independent from each other. A file system failure in one LVM volume does not affect any of the other volumes. All data in other volumes are safe. In BTRFS, everything is a single huge file system, (sub)volumes are just logical groupings within a single, in the worst case faulty, file system.
You just described "LVM technology": keeping everything (except boot) in one or more partitions or disks logically combined as if only one, with subsections able to be allocated more or less size, and partitions and/or disks added or removed, all while actively in use.
On Fri, Sep 15, 2023 at 3:57 AM Peter Boy pboy@uni-bremen.de wrote:
Am 15.09.2023 um 04:57 schrieb Felix Miata mrmazda@earthlink.net:
BTRFS devs seem to think only one is somehow better due to its inclusion of LVM technology.
There is no „inclusion of LVM technology“ in BTRFS. LVM provides you with several separate filesystems, completely independent from each other. A file system failure in one LVM volume does not affect any of the other volumes. All data in other volumes are safe. In BTRFS, everything is a single huge file system, (sub)volumes are just logical groupings within a single, in the worst case faulty, file system. The advantage of BTRFS is greater flexibility and effectiveness of disk capacity usage, at the expense of data protection.
BTRFS protects us from "silent" corruption of files, which is more of an issue with large volumes of data. The greater flexibility and effectiveness of BTRFS minimizes the need to reorganize filesystems when a partition runs out of space. For large organizations with many users, btrfs is expected to reduce problems with data corruption, time spent paying users to do housekeeping tasks, and the added wear on flash memory of reorganizing filesystems.
On 9/15/2023 2:56 AM, Peter Boy wrote:
Am 15.09.2023 um 04:57 schrieb Felix Miata mrmazda@earthlink.net:
BTRFS devs seem to think only one is somehow better due to its inclusion of LVM technology.
There is no „inclusion of LVM technology“ in BTRFS. LVM provides you with several separate filesystems, completely independent from each other. A file system failure in one LVM volume does not affect any of the other volumes. All data in other volumes are safe. In BTRFS, everything is a single huge file system, (sub)volumes are just logical groupings within a single, in the worst case faulty, file system. The advantage of BTRFS is greater flexibility and effectiveness of disk capacity usage, at the expense of data protection.
WHat is the reason Peter behind xfs being used on the server edition and btrfs on the workstation? I pretty much stick with ext3. I don't even use ext4 really. I've never used xfs.
Bill
Bill Cunningham composed on 2023-09-15 11:23 (UTC-0400):
WHat is the reason Peter behind xfs being used on the server edition and btrfs on the workstation? I pretty much stick with ext3. I don't even use ext4 really.
I use EXT3 and EXT4. EXT4 is much faster.
Am 15.09.2023 um 17:23 schrieb Bill Cunningham bill.cu1234@gmail.com:
...
WHat is the reason Peter behind xfs being used on the server edition and btrfs on the workstation? I pretty much stick with ext3. I don't even use ext4 really. I've never used xfs.
Bill
It is basically about data protection, performances, reliability and easy administration (see https://docs.fedoraproject.org/en-US/server-working-group/docs/server-techni...) So, the Fedora server editions (i.e. Server and CoreOS) use LVM/xfs.
And please, think twice when you read something like "BTRFS protects us from "silent" corruption of files, which is more of an issue with large volumes of data“ or „... large organizations with many users, btrfs is expected to reduce problems with data corruption…“. It’s more kind of marketing speech than any valid decision criteria or technically based argument. If you use the search engine of your preference you will find a lot of detailed and and technically based discussions of Fedora and Red Hat engineers about the topic. As in most cases, there is no „one absolute truth“ about filesystems as many missionaries claim again and again. It is a question of weighing and criteria for a use case or also for a type of use cases.
Peter
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
On 2023-09-15 2:07 p.m., Peter Boy wrote:
Am 15.09.2023 um 17:23 schrieb Bill Cunningham bill.cu1234@gmail.com:
WHat is the reason Peter behind xfs being used on the server edition and btrfs on the workstation? I pretty much stick with ext3. I don't even use ext4 really. I've never used xfs.
It is basically about data protection, performances, reliability and easy administration (seehttps://docs.fedoraproject.org/en-US/server-working-group/docs/server-techni...) So, the Fedora server editions (i.e. Server and CoreOS) use LVM/xfs.
And please, think twice when you read something like "BTRFS protects us from "silent" corruption of files, which is more of an issue with large volumes of data“ or „... large organizations with many users, btrfs is expected to reduce problems with data corruption…“. It’s more kind of marketing speech than any valid decision criteria or technically based argument. If you use the search engine of your preference you will find a lot of detailed and and technically based discussions of Fedora and Red Hat engineers about the topic. As in most cases, there is no „one absolute truth“ about filesystems as many missionaries claim again and again. It is a question of weighing and criteria for a use case or also for a type of use cases.
Umm, no.
Fedora server uses LVM because that's what most people have upgraded from. It adds another data layer to the i/o stack, increasing on-disk complexity. It is normally required under XFS to provide the missing pieces like RAID levels and snapshots, as XFS was designed in the 70s with hardware RAID in use. Its also what most sysadmins were trained to use, and its hard to change old habits. Its solid, but really old tech that BTRFS and ZFS can almost always do better. Unlike LVM, RAID-5/6 is currently a problem for BTRFS, as it has the write-hole bug that almost all hardware and software implementations also have with the exception of ZFS. Disks are really cheap, so 2 or 3-way mirroring or RAID-1 are currently the ways to go on BTRFS. It should be noted that imho the RAID-Z levels on ZFS are superior to all other solutions for reliable data preservation and performance.
Fedora server uses XFS because that's what RHEL and therefore the certified sysadmins use. Consumer disks are actually more reliable than enterprise disks, but stall for very long periods when re-reading failing sectors. So, BTRFS actually works better on enterprise disks, as the stall is far smaller. It is probably the #3 or 4 filesystem around for performance and reliability, but managing it is positively arcane. There are a number of normal admin operations that are very difficult using XFS, such as shrinking a filesystem (even by a couple of sectors to use a replacement disk). It also does no runtime error detection/correction of your data, so you depend upon RAID hardware or LVM to do that for you. If you get an error detected during one of these repair sweeps, recovery is usually no better than an uncorrectable multi-bit BTRFS or ZFS failure. Putting XFS on a single disk is very questionable as a result.
Fedora desktop uses BTRFS by default for a number of really good reasons. BTRFS detects bit-rot on the fly. With mirrored or RAIDed disks it can also correct that bit-rot on the fly. XFS cannot do that, and requires weekly error detection work. Putting ZFS or BTRFS on RAID hardware actually makes everything slower, as they do a better, faster and more reliable job in software. BTRFS and ZFS also have many operational advantages, like much faster migrations, near-instantaneous snapshotting and rollback (LVM takes hours to do the same), and much faster off-machine backups.
While ZFS is the gold standard for reliable filesystems, with the exception of the Ubuntu and Oracle platforms, it cannot be used without paying Oracle lots of money. BTRFS reimplements much of ZFS in a legally unencumbered codebase. It is unclear why Fedora has not moved server installs to BTRFS by default, as the advantages in complexity, training and data reliability are huge. Those all make a BTRFS or ZFS server cheaper to operate, sometimes by a considerable margin. I know all the RHEL sysadmin people will come out of the woodwork and start shouting about that statement, but just maybe they are incorrect. YMMV of course.
On 09/15/2023 02:20 PM, John Mellor wrote:
Fedora desktop uses BTRFS by default for a number of really good reasons. BTRFS detects bit-rot on the fly. With mirrored or RAIDed disks it can also correct that bit-rot on the fly.
And what advantages does either it or LVM have for a home user with one desktop and one laptop?
On 9/15/23 14:05, Joe Zeff wrote:
On 09/15/2023 02:20 PM, John Mellor wrote:
Fedora desktop uses BTRFS by default for a number of really good reasons. BTRFS detects bit-rot on the fly. With mirrored or RAIDed disks it can also correct that bit-rot on the fly.
And what advantages does either it or LVM have for a home user with one desktop and one laptop?
The advantage btrfs has is that the volumes share the same space. So you can have / and /home be separate, but you don't have to decide on how much space each one gets. And you can still do a re-install while keeping the files in /home. Also, if the drive runs out of space, you can expand the filesystem onto another drive. Snapshots can also be nice in certain cases.
On 09/15/2023 03:11 PM, Samuel Sieb wrote:
The advantage btrfs has is that the volumes share the same space. So you can have / and /home be separate, but you don't have to decide on how much space each one gets. And you can still do a re-install while keeping the files in /home. Also, if the drive runs out of space, you can expand the filesystem onto another drive. Snapshots can also be nice in certain cases.
Considering how big drives are today and that I specified a home user, how likely is it that you're going to run out of space? I have never seen the slightest need for LVM on a home box, but it's still the default on all of the workstation spins.
On Fri, 2023-09-15 at 15:17 -0600, Joe Zeff wrote:
On 09/15/2023 03:11 PM, Samuel Sieb wrote:
The advantage btrfs has is that the volumes share the same space. So you can have / and /home be separate, but you don't have to decide on how much space each one gets. And you can still do a re-install while keeping the files in /home. Also, if the drive runs out of space, you can expand the filesystem onto another drive. Snapshots can also be nice in certain cases.
Considering how big drives are today and that I specified a home user, how likely is it that you're going to run out of space? I have never seen the slightest need for LVM on a home box, but it's still the default on all of the workstation spins.
The default for F38 (workstation) is BTRFS. I dumped LVM for BTRFS years ago and have been happy with it. Not having to think about partitions is a big win. I've even set up a subvolume for hibernation so as not to dedicate a swap partition to that.
poc
Am 15.09.2023 um 23:11 schrieb Samuel Sieb samuel@sieb.net:
The advantage btrfs has is that the volumes share the same space. So you can have / and /home be separate,
Think again, you hopefully recognize the 'contradictio in adiecto' yourself.
And you can still do a re-install while keeping the files in /home.
You can do that as long as you have no serious filesystem issue and you don’t need to reformat ROOT. But in such a case you can do that with any plain filesystem as well. That is no specific advantage of BTRFS at all.
If you have to reformat while installing, all your data in /home are lost as well in case of BTRFS subvolumes. But they are not lost in case of LVM volumes.
BTRFS is perfectly OK for desktop and laptops. Fortunately you don’t need to reformat that often, nowadays. But everyone should clearly know what is going on. And you should really stop to spread misleading information! This could be dangerous for precious data of other users.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
Am 15.09.2023 um 23:05 schrieb Joe Zeff joe@zeff.us:
On 09/15/2023 02:20 PM, John Mellor wrote:
Fedora desktop uses BTRFS by default for a number of really good reasons. BTRFS detects bit-rot on the fly. With mirrored or RAIDed disks it can also correct that bit-rot on the fly.
And what advantages does either it or LVM have for a home user with one desktop and one laptop?
Well, the Workstation Edition Working Group discussed that about 1 or 2 years ago, I don’t remember the time. I didn’t participate in that discussion. But I strongly assume they carefully weighed the technical arguments at hand and then came to the decision that for most desktop use cases BTRFS is the better solution **overall**. So this became the default configuration. The user can decide otherwise during the installation.
Forget all the detail-obsessed single bogus arguments like "can also correct the bit-red on the fly". In the end, this is a highly complex technical consideration and each solution has its advantages and disadvantages.
Fedora is known for its high technical quality and for ensuring secure usage already in the default configuration. From the technical side, it is therefore generally best to use the default configuration!
From the *practical* side, perhaps it would be worth considering whether your use case is the usual and common case - 6-16 GB RAM, 500GB - 1TB disk, regular (hourly) backup, etc. And in case of emergency, you are the only one affected, not hundreds of other users at the same time. With the workstation default configuration, you give up the separation of system and user data that has been proven for Unix systems for decades, in favor of greater flexibility and less administrative effort. I think this is a sensible decision in view of today's disk technology. But don't fall for the "/" and "/home" subvolumes. That's not a Unix-proven separation, it is just a logical grouping, especially to enable image-based backups / snapshots. In the worst case of a file system error or a serious operating system error in the ROOT subvolume, all your data is lost and you need the backup. A BTRFS subvolume is not a separate filesystem as a LVM volume is! But most likely you will either never or most rarely in a few years, experience such a disaster. Until then, you can use and enjoy the benefits of BTRFS.
For a server with 8, 12 or more TB disks (and user data) and maybe hundreds of users the situation is quite different. Therefore we decided for LVM/XFS, giving data protection, reliable and as possible uninterrupted operation and, in the worst case, damage with the least possible effect the highest priority - at the cost of increased administration effort and higher costs.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
On Sat, 2023-09-16 at 09:17 +0200, Peter Boy wrote:
From the *practical* side, perhaps it would be worth considering whether your use case is the usual and common case - 6-16 GB RAM, 500GB - 1TB disk, regular (hourly) backup, etc.
I would say the *most* usual and common would be no backups made at all.
I'd also say that *most* people using a computer are only semi-literate about computing. It's gone from only nerds with a keen interest are using computers to virtually everyone is expected to, no matter how little their care about it.
Backing things up, *and* being able to restore something is far from straight-forward. You really need something external to back up to, it may well be best that it's not another computer with the same OS, since and OS update may be what caused your need to restore files. You need to know how to drive it. How to backup what you need to backup, how to ignore things that don't need backing up that would waste time and space. And you really need to know how to retrieve something specific that you lost, because a simple dump everything you have now in the trash and put back on everything from an hour (or more) ago causes far more loss than the one file you needed to get back.
On Sat, Sep 16, 2023 at 6:56 AM Tim via users users@lists.fedoraproject.org wrote:
On Sat, 2023-09-16 at 09:17 +0200, Peter Boy wrote:
From the *practical* side, perhaps it would be worth considering whether your use case is the usual and common case - 6-16 GB RAM, 500GB - 1TB disk, regular (hourly) backup, etc.
I would say the *most* usual and common would be no backups made at all.
Windows and macOS both copy user data to cloud servers, so many users new to linux have no experience with backups. Users who create artifacts, including emails, generally store them on a remote server.
I'd also say that *most* people using a computer are only semi-literate about computing. It's gone from only nerds with a keen interest are using computers to virtually everyone is expected to, no matter how little their care about it.
At my former workplace, each user was issued a Windows laptop configured with a personal directory and a shared workgroup direcotory in an enterprise "cloud" . Important content should be placed in the appropriate cloud location. When a laptop has problems that don't have a quick solution, the disk is wiped and a fresh enterprise Windows image is installed.
Backing things up, *and* being able to restore something is far from straight-forward. You really need something external to back up to, it may well be best that it's not another computer with the same OS, since and OS update may be what caused your need to restore files. You need to know how to drive it. How to backup what you need to backup, how to ignore things that don't need backing up that would waste time and space. And you really need to know how to retrieve something specific that you lost, because a simple dump everything you have now in the trash and put back on everything from an hour (or more) ago causes far more loss than the one file you needed to get back.
I think many linux users have ways to keep important content in cloud locations. Backups provide faster recovery if the one and only disk fails, but the user's important content is not at risk.
Problems occur for users who heavily customize the system so there is a lot of work to be done after a fresh OS install. Customizations also make it harder to get help from forums when they introduce problems that don't occur in normal installations.
Am 15.09.2023 um 22:20 schrieb John Mellor john.mellor@gmail.com:
...
Umm, no. Fedora server uses LVM because that's what most people have upgraded from.
We had an intensive discussion on our working group about the default file system. Obviously, I missed you? Or did I just imagine the extensive discussion? Have we all just simply updated?
... It is unclear why Fedora has not moved server installs to BTRFS by default, as the advantages in complexity, training and data reliability are huge.
Yeah, we are just all too stupid and stubborn, that we could understand all your valuable and undoubtedly solely true insights.
A little more expertise wouldn't hurt. And „ipse se nihil scire id unum sciat“ [1], even Socrates, 469 to 399 B.C., was more advanced in his cognitive abilities.
[1] Cicero, Academia 1,16, Latin, because of problems with the Greek character set here. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
-
Bill Cunningham -
Felix Miata -
George N. White III -
Joe Zeff -
John Mellor -
Patrick O'Callaghan -
Peter Boy -
Samuel Sieb -
Tim