Did I enter protected mode right?

Index > OS Construction > Did I enter protected mode right?

Goto page Previous 1, 2

Author

Thread

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 21091
Location: In your JS exploiting you and your system

revolution 20 Aug 2026, 22:08

bzt wrote:

... a UNIX clone like Linux usually needs multiple partitions (root, home, usr, var, etc.).

My Linux system has a single partition, root.

20 Aug 2026, 22:08

bzt

Joined: 09 Nov 2018
Posts: 110

bzt 21 Aug 2026, 15:31

revolution wrote:

bzt wrote:
... a UNIX clone like Linux usually needs multiple partitions (root, home, usr, var, etc.).
My Linux system has a single partition, root.

Possible, but extremely inefficient and highly risky. Using different partitions allows you to tweak the file systems according to their usage: usr usually has rarely-changing static larger files, var has lots of often-changing small files for example; you probably want to only allow device files in dev nowhere else; no access time and execution right on files in tmp, etc. If home is separated then you can reinstall the system without losing your own files etc. etc. etc.

(ps. see tune2fs, a typical distro installer calls this automatically, it only asks you what are you going to use the partition for, the tweaking is taken care for you.)

21 Aug 2026, 15:31

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 21091
Location: In your JS exploiting you and your system

revolution 21 Aug 2026, 21:23

bzt wrote:

Possible, but extremely inefficient and highly risky. Using different partitions allows you to tweak the file systems according to their usage: usr usually has rarely-changing static larger files, var has lots of often-changing small files for example; you probably want to only allow device files in dev nowhere else; no access time and execution right on files in tmp, etc. If home is separated then you can reinstall the system without losing your own files etc. etc. etc.

I wonder if that is conflating mount points with partitions.

I have many mount points, on a single partition

For example tmp is mounted as a ram disk, dev is mounted udev etc.

Code:

udev on /dev type devtmpfs (rw,nosuid,relatime,size=7931608k,nr_inodes=1982902,mode=755,inode64)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=7970804k,nr_inodes=1048576,inode64)

21 Aug 2026, 21:23

bzt

Joined: 09 Nov 2018
Posts: 110

bzt 23 Aug 2026, 13:00

revolution wrote:

I wonder if that is conflating mount points with partitions.

I'm not sure I follow.

revolution wrote:

I have many mount points, on a single partition

That's irrelevant, mount points are handled by the VFS subsystem, unrelated to the block device layer. It doesn't matter if your mount points are located on a single file system or spread out on multiple file systems on multiple devices and partitions.

revolution wrote:

For example tmp is mounted as a ram disk, dev is mounted udev etc.

These are special file systems without any block device backing, so they work regardless to the disks and partitioning scheme.

Their path is special, see FHS, but it doesn't matter if their parent directory, the root is mounted from a partition or from an another ramdisk, etc. Likewise, tmp could be backed by an actual partition, a ramdisk device as well; and dev could be an ext4 partition for example with actual device files on it too (see mknod). The tmpfs and udev pseudo file systems are just much more efficient solutions, plus udev is dynamic (device files appear and disappear automatically as they needed).

For an extreme, take a look at tinycore linux. Here the root is just a ramdisk, and every installed software is also a mount point (a loopback device mounted image file). So here all is handled by VFS alone, no disks and no partitions, the block device layer is simply unused (except for the loopback device). This works very fast at first, but after you install some packages, you'll see the VFS can't cope with many mount points and the whole system seriously slows down. This has nothing to do with any partitions or where the mount points located, just their number matters (to be precise, the "which mount point a certain path belongs to" lookup is O(n*m) in the Linux kernel).

23 Aug 2026, 13:00

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 21091
Location: In your JS exploiting you and your system

revolution 23 Aug 2026, 13:15

I queried because the comment I quoted talked about tmp and dev in relation to a single partition being risky. But I didn't see how mounts points are related to partitioning. They are orthogonal.

Anyhow, it was also to imply that Linux doesn't need more than one partition, and an MBR can support Linux perfectly fine. Indeed this box I am using now uses an MBR with a single partition. Maybe the old MBR isn't so bad after all, it can still support contemporary OSes today.

23 Aug 2026, 13:15

bzt

Joined: 09 Nov 2018
Posts: 110

bzt 23 Aug 2026, 19:01

revolution wrote:

I queried because the comment I quoted talked about tmp and dev in relation to a single partition being risky.

Obviously those are irrelevant and those are not the risky part. Tmp is by definition destructed on each reboot, and dev is dynamically created, so nothing to loose with those. But back then, there was no tmpfs nor udev, so the files in those locations were actually written on disk (powerusers might have created a ramdisk for tmp (a block device, not a pseudo file system!), but there was no such thing for dev).

What I meant by risk, Linux needs to write files frequently to certain locations (notably under /var, to be precise /var/run, /var/cache, /var/log, etc.), which puts a stress on the device (most notably on the sectors where the superblock resides, but other meta data needs to be written too). If you have only one partition with only one file system, then all writes alter that one superblock. Should that single file system get corrupted, you're screwed. On the other hand, if root, /var, /home and /usr are separate, then you can tune them properly, write their meta data separately, meaning lower risk of corrupting everything all at once, and even if var goes havoc for example, your precious family photos on the home file system will be safe. And vice versa, if you accidentally fill up your /home, that won't affect /var, and for example your graphical session won't crash because it still can create secure cookie files or named pipes or whatever it needs to function.

revolution wrote:

But I didn't see how mounts points are related to partitioning. They are orthogonal.

Nope, they are not orthogonal. All partitions needs to be mounted somewhere in order to use the files on it, but not all mount points are backed by a partition (to be precise, not partition, file system).

revolution wrote:

Anyhow, it was also to imply that Linux doesn't need more than one partition, and an MBR can support Linux perfectly fine.

Yeah, until you learn what tunefs is, and/or want to dual boot something else too.

revolution wrote:

Indeed this box I am using now uses an MBR with a single partition.

Huh, you like to live dangerously, don't you? See the risks above.

Also these days firmware mandate a separate /boot partition (UEFI ESP) too. While it's certainly possible, I definitely would not recommend using a FAT formatted ESP as your Linux root file system. Just because you can do it, doesn't mean you should.

revolution wrote:

Maybe the old MBR isn't so bad after all, it can still support contemporary OSes today.

Nope, it can't. My machine for example has no CSM any more (meaning ESP is mandatory), and MBR can't describe my disks (simply does not fit, bigger than 2^(32+9), we live in the terrabyte storage era).
Good luck trying to install and boot a contemporary Win11 for example on old MBR scheme. Maybe possible, but definitely won't worth the effort.

23 Aug 2026, 19:01

Furs

Joined: 04 Mar 2016
Posts: 2747

Furs 25 Aug 2026, 21:46

bzt wrote:

Huh, you like to live dangerously, don't you? See the risks above.

Also these days firmware mandate a separate /boot partition (UEFI ESP) too.

It doesn't have to be separate, it just has to be FAT32 because that's the required filesystem that all UEFI implementations must support per spec. It doesn't mean a possible UEFI implementation can't support a Linux filesystem like ext4 or any other filesystem. It just makes FAT32 guaranteed to work.

Anyway, you're overcomplicating shit with your millions of partitions. Keep it simple.

In my case, I have a complete immutable root filesystem stored in a squashfs, with an overlayfs on top, which I make either a tmpfs upperdir, or somewhere on disk if I want changes saved or to inspect later. So all root writes/updates are temporary, which is perfect for most daily usage and much safer since the root filesystem itself is immutable; one time I completely borked a core library so no apps could launch anymore, and guess what, I just restarted the PC and it was back to normal since the writes were temporary only.

Your millions of partitions don't offer any real safety in comparison. /var/log writes or whatever also go to tmpfs so nothing is torturing my disk (and there's less than you think, can easily inspect what changed by checking the upperdir).

You know what else is good about it? All it takes to backup my root is a copy of a single file (the squashfs) and it can be copied anywhere on any other filesystem, even a DVD. Backing up a partition on the other hand can be a pain in the ass.

The only thing that requires more though is updating it—but that's good because you should be careful doing updates and only update what's necessary or what you know will be updated.

Did an update completely bork my system? No worries just copy back the squashfs backup and restore is done. No complicated bullshit "backup and restore" apps.

25 Aug 2026, 21:46

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 21091
Location: In your JS exploiting you and your system

revolution 26 Aug 2026, 00:56

bzt wrote:

revolution wrote:
Maybe the old MBR isn't so bad after all, it can still support contemporary OSes today.
Nope, it can't. My machine for example has no CSM any more (meaning ESP is mandatory), and MBR can't describe my disks (simply does not fit, bigger than 2^(32+9), we live in the terrabyte storage era).

That conflates the machines with the OS. A machine manufacturer removing support for MBR booting is not the fault of the OS or MBR. Blame is on the manufacturer for making their system less flexible.

bzt wrote:

Nope, it can't.

It only needs one data point to show that it can. All the systems here can, and do. So I have multiple data points showing that the MBR is still relevant today.

I judge that as a success for MBR.

26 Aug 2026, 00:56

bzt

Joined: 09 Nov 2018
Posts: 110

bzt 05 Sep 2026, 14:15

Furs wrote:

Anyway, you're overcomplicating shit with your millions of partitions.

Not millions, just five, and not overcomplicated, just tuned properly (done automatically by the installer may I add). Separating at least /boot and /home from the rest of the system is the sane thing to do.

Furs wrote:

Your millions of partitions don't offer any real safety in comparison.

Not millions, just five, and it is real safety. I had to do a clean install on one of my machines last month, and my files and custom configs under /home were safe and kept.

Furs wrote:

/var/log writes or whatever also go to tmpfs

No, they do not. No writes to /var/log, /var/tmp, /var/cache etc. go through tmpfs, never ever. Run the apps through strace and see for yourself.

Furs wrote:

so nothing is torturing my disk (and there's less than you think, can easily inspect what changed by checking the upperdir).

Yes, it does torture your disk, and you should use iotop and lsof commands to see that. Or maybe SKrellM, which is a GUI monitor on your desktop (the disk plugin can be configured to show partitions separately).

revolution wrote:

A machine manufacturer removing support for MBR booting is not the fault of the OS or MBR. Blame is on the manufacturer for making their system less flexible.

No and yes. My disks are simply larger that what MBR can cope with, that's neither the OS's nor the firmware's fault. And yes, lack of MBR boot is the firmware manufacturer's fault, but that does not change the fact that my machines can't boot an OS from MBR any more.

Furthermore some contemporary OSes have removed MBR booting support as well, GPT is mandatory for Windows since W11 24H2. Circumventing simply does not worth the effort, and firmware these days can't boot it anyway.

revolution wrote:

So I have multiple data points showing that the MBR is still relevant today.

Not relevant for me (for years now). Like I've said, I have exactly zero real machine that could boot from it.

05 Sep 2026, 14:15

Goto page Previous 1, 2

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum