• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Partitioning scheme in linux...

A

AznMaverick

Platinum Member
i'm thinking of installing red hat 9, but i want to figure out a partitioning scheme to make things easier. i've googled around and found some different answers. i just wanted some input from experts like you. i was thinking of the following:
/swp 250MB
/boot 50MB
/home 800MB
/ 200MB
/var 200MB
/usr 200 MB

i'm not really sure about usr home and the root directory's amount....any input welcome.

Thanks.
 
Originally posted by: AznMaverick
i'm thinking of installing red hat 9, but i want to figure out a partitioning scheme to make things easier. i've googled around and found some different answers. i just wanted some input from experts like you. i was thinking of the following:
/swp 250MB
/boot 50MB
/home 800MB
/ 200MB
/var 200MB
/usr 200 MB

i'm not really sure about usr home and the root directory's amount....any input welcome.

Thanks.
Click to expand...

I'd just make a root and a swap. With such little diskspace you need to use all that you can get and can't afford to waste it. A small home partition is good, maybe 200-300 megs, then a swap is needed and a boot partition is a good idea. If you had more space to work with then I would say that that would be a excellent partitioning sceme, if you could make it porptionally bigger.

Sorry, but Redhat 9 isn't going to work on that either. RH is a modern desktop in all sense of the word, including bloat. With a normal install it would probably be just as big as install XP with all the updates, patches and service packs.

What you got their is 2 gigs of space.

You could fit it on there if you use minimal stuff, but on something that small I would think it would be better if you choose SLackware instead. I've haven't seen the new version yet, but it's generally not all that harder to install Slackware then it is to install Redhat.

Just do a newbei install (if that's still a option) and choose to install X, but leave out the desktop enviroment. Install in it's place a Window manager Like fluxbox, or more windows-like IceWM.

With luck you can probably keep the install footprint under a gig of harddrive space.

Now if you had a bigger harddrive, I would recommend Redhat. You can probably still install RH if you want to, just try to keep it a bit minimalistic.
 
Originally posted by: AznMaverick
i can get rid of 2 mroe gigs of space on the drive...what do you recommend for a red hat install?
Click to expand...

That's about right. 3-4 gigs. Just don't install everything.
 
You're over complicating it, I just do / /home and swap whenever I can.

And the fact that you only made /usr 200M will probably make the install fail because that's not very much space.
 
Maybe this is entirely OpenBSD specific, but here are a couple of reasons from their FAQ as to why you should create seperate partitions:

Security: You can mark some filesystems as 'nosuid', 'nodev', 'noexec', 'readonly', etc. This is now done by the install process, in fact, if you use the above described partitions.

Stability: A user, or a misbehaved program, can fill a filesystem with garbage if they have write permissions for it. Your critical programs, which of course run on a different filesystem, do not get interrupted.

Speed: A filesystem which gets written to frequently may get somewhat fragmented. (Luckily, the ffs filesystem, what OpenBSD uses, is not prone to heavy fragmentation.)

Integrity: If one filesystem is corrupted for some reason then your other filesystems are still OK.

Size: Many platforms have limits on the area of a disk where the boot ROM can load the kernel from. In some cases, this limit may be very small (504M for an older 486), in other cases, a much larger limit (8G on new i386 systems). As the kernel can end up anywhere in the root partition, the entire root partition should be within this area. For more details, see this section. A good guideline might be to keep your / partition completely below 2G, unless you know your platform (and particular machine!) can handle more (or less!) than that.

And of course, the only system I have that did not follow these guidelines is my Debian system...
 
As the kernel can end up anywhere in the root partition, the entire root partition should be within this area
Click to expand...

On most Linux systems the kernel is under /boot, so only /boot need be in whatever limits your system imposes.
 
Originally posted by: Nothinman
As the kernel can end up anywhere in the root partition, the entire root partition should be within this area
Click to expand...

On most Linux systems the kernel is under /boot, so only /boot need be in whatever limits your system imposes.
Click to expand...

I don't think Linux systems really have this problem. That is why I prefaced it with the fact that this might be OpenBSD specific. 😉
 
Originally posted by: n0cmonkey
I don't think Linux systems really have this problem.
Click to expand...
That's the old "cylinder 1024" problem - it was generally advisable to use a small /boot partition to ensure the kernel lived a cylinder <1024. If you didn't use /boot, then the entire root partition would have to fit that limit.

It's been a long time since that's been an issue, though. Any hardware from at least the last 5 years supports LBA addressing, which allows you to break the limit. For a while, LILO didn't have LBA support, which is why people still remember the issue. But with any non-antique Linux distro, "cylinder 1024" is a non-issue unless you're installing on an absolute dinosaur of a machine.

 
n0c, there are very good reasons for having seperate partitions, and you covered most if not all of them. However, it's bad for a newbie becasue it's virtually impossible to change it if you screw up. parted can't move the beginning of a ext2 partition non-destructively.

Just for reference, here is the actual disk usage of my main debian system after about a year of use. In my case, I just have /boot, /, and /swap partitions. When I get my new laptop in a few weeks, I'll make a /tmp also, so that I can have 2 distros at the same time share that space.

39M /boot
799M /home
317M /var
2.6G /usr
845M / (everything else)
1 G /swap (512 mb of ram)
 
When I get my new laptop in a few weeks, I'll make a /tmp also, so that I can have 2 distros at the same time share that space.
Click to expand...

How do you plan to do that? log on as a user to the 'host' machine from the laptop?
 
Originally posted by: n0cmonkey
Maybe this is entirely OpenBSD specific, but here are a couple of reasons from their FAQ as to why you should create seperate partitions:

(excellent advice snipped to avoid lengthy repetitive quotes)
Click to expand...
Amazingly, I could understand most of what you said, but I'm going to have to do some reading on the "nodev," "nosuid," and "noexec" things to see what they mean. I'm not sure how well XFS handles fragmentation, but I've not had any noticeable problems yet. Gentoo Linux leaves /boot unmounted during everyday operations; I think this is for protection from PEBCAK screw-ups and possibly for security as well, but I can't claim to fully understand why (and I'm tired now, thus too lazy to research it).
 
Originally posted by: jliechty
I'm not sure how well XFS handles fragmentation, but I've not had any noticeable problems yet.
Click to expand...
Like other Linux filesystems, fragmentation is not an issue for typical operations.
Gentoo Linux leaves /boot unmounted during everyday operations; I think this is for protection from PEBCAK screw-ups and possibly for security as well, but I can't claim to fully understand why (and I'm tired now, thus too lazy to research it).
Click to expand...
PEBCAK mostly, not security. The idea is that the OS only needs /boot to... well... boot. After that, it doesn't touch those files at all. So leaving /boot unmounted means it can't get borked by some nasty file corruption or user error. Of course, there are plenty of other files you can screw up with either of those, but leaving /boot unmounted seems a simple enough precaution. I don't think it warrants a separate partition since, as mentioned, there are plenty of other disastrous possiblities. But if you've got to have a /boot partition for some reason, you might as well leave it unmounted. Security, on the other hand, isn't much of issue. Nobody can do anything in /boot apart from root anyway, and pretty much all the information a malicious user would want can be found elsewhere, particularly in /proc.

 
First, I didn't write that. I stole it straight from the OpenBSD FAQ. 😛

I don't know about the rest of you, but I reinstalled Linux quite a few times, especially when I had just started using it. Changing around partition sizes at that point was easy.

Lastly, I didn't mean that other ways are wrong, just that there is not a best way to do things.
 
I'm a newbie myself running Slackware 9.1 and I love it. I can configure my system under Slackware using command line faster than Mandrake 9.2 (RC2) or RH9 gui's... plus, it just feels right doing it that way 😉

As for your partitions, I've always asked around about the advantages to having multiple partitions, but never got a really good answer (until I read n0cmonkey's OpenBSD FAQ rewrite 😉) . If I were you, I'd go with just the root (/) partition and swap, then get to know your system before doing anything fancier.
 
I personally like to have a boot partition to avoid corrupting my kernel. It's a small thing, but I like it. I also like having a home partition. This is so that's easier to protect my configurations to the desktop and my personal files and notes as I go from distro to distro. (seems like I am sticking to debian, though). Other then that I have a "share" partition for my roomates to use for their own files (they have small HD, I got 8o- giger, more then enough for me)

The rest gets stuck under the root partition.
 
The only way to know how big parititons should be is to know how much you're going to install on them. Don't worry until you have specific needs for backups, filesystems, or performance. The unix FS is arranged according to the approximate modification and size characteristics of the files in that part of the FS. e.g., /usr is slowly changing and small-to-mid sized files. /var is rapidly changing and variously sized. Those are the two main partitions that you should consider creating when you're more familiar with what you're doing and installing. Separating that stuff into separate partitions allows the FS parameters to be tuned for those uses and for fragmentation to be kept to a minimum. Also, the partitions can be placed on disk where the throughput and latency best benefit the system's performance.

I'd separate /home so you can reformat and not lose user data. Also, it's the most important part of the FS to backup, and separating it into a separate partition allows you to use dump/restore for backups.
 
Originally posted by: cleverhandle
Security, on the other hand, isn't much of issue. Nobody can do anything in /boot apart from root anyway, and pretty much all the information a malicious user would want can be found elsewhere, particularly in /proc.
Click to expand...
And if anyone got root, they could mount the partition anyway.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top