Hi there,

I always create 2 partitions, one swap and one for '/'. I think this is a good way to use the space in your hard drive.

sharky2x2x

No it's definately not. Next time please read the whole tread first.

Well, not at all meant as an offense, but that's a bit paradox (or maybe I got you wrong, as I am not a native English speaker; in that case, please, explain).

It's a lot less likely that a partition gets full, when you have few, large partitions, than when you fragment your disc in multiple smaller ones. The latter may, however, be better for the overall performance, if you do it right.

So having only / and swap is certainly ok for many people. Although I'd recommend to have a separate /home partition, at least.

The problem with partitioning is that you need to know in advance, what precisely you want to do with your system, and how much space each function requires. Eg, on a server system you will usually provide a relatively large space for /var/log. But how large is that exactly? If this is a separate partition, however, and it gets full, the whole system gets stuck. If, however, this is just a directory under the / partition, it can grow as long as there's space on that larger partition available.

Given that SuSE is popular with web hosters and other large sites, I am inclined to think that they know what they are talking about. And therefore, forgive me, I cannot subscribe to your point of view (and the somewhat rough way you expressed it) that only / and swap aren't a good idea. It's good enough for the vast majority of systems and users, although I still recommend to have third partition, /home.

But if your point was that the system may just go berserk, then you are right. But I've never experienced that in over ten years on any Linux system, with the exception of a crashed hard disc; and no partitioning scheme whatsoever will protect you against that type of hardware failure. (A RAID system could save you, of course).

gargamel

This is the problem exactly, though you have it a bit mixed up.

If you placed system logs on another partition, and that partition were to become filled by excessively large log files, then the system would simply stop writing log files. It wouldn't lock up or become unusable, it just couldn't write logs until the problem was resolved.

On the other hand, you had these log files on a small-ish root partition, and it were to become filled, the system would be unusable. This is enough of a problem that in the earlier days of the Internet, when you only had a 20 MB HDD on your server, a viable DoS attack was to simply cause a server to log excessively (for example, with a lot of failed logins).

The same is true with putting /home on it's own partition. Anything that is likely going to be filled with large files that only get larger should be pushed off of the primary partition for the sake of stability.

The argument could be made that with drives as large as they are today, we no longer have to worry about jambing a partition with log files. While that is largely true, there is no reason to abandon organization and modularity simply because HDD technology has improved.

Perfect explanation, thanks for correcting me!

gargamel

Linux of course allows you to go mad and create a complete forrest of partitions.

I would say as a minimum create 2:
/ root
swap

Many distros will also put /boot on a separate partition (although I have forgotten what the reason was. Security?). So that should probably be next if you want to add 3.

If you want to play around with upgrading and trying different distros, having your user files on a separate partition is probably priority 4. So a partition for /home

As you see from the responses above there are others in use too. You can find documents online with recommendations. Particularly if you want to practice being sysadmin on Linux servers. Also look around for recommended sizes. Linux file systems are pretty good at managing large disks, so don't think you need to worry about speed on large partitions.

Hi,

The basic reason was to keep the 1024 cylinder limit from causing a problem. You would create the '/boot' at the start of the disk which would be within the 1024 address area. Therefore the boot for vmlinuz could be performed from that area.

Okay, it's not completely there with Linux, but most if not all these partitioning and sizing issues simply do not exist whith ZFS ...

Hi,

The 1024 cylinder limit is really not a problem any longer for Linux. This subject always pops up. The old 1024 cylinder problem will bite you on older hardware but with leading edge then you should not see it.

As for the 'ZFS', your choice. Just another FS but FUSE is still needed with Linux. Unless you use the 'Correia deamon' then the speed is really poor as compared to other FS.

At least with 'FUSE' you can get some performance for 'ZFS, NTFS, etc.

Now if you are speaking strictly with ZFS and Solaris then by all means there are no limitations.

ZFS is best for systems that have a Forth base bootstrapping mechanism. Especially on a sunny day. ;-)

gargamel

I completely disagree with your view, and I think that MS3FGX's take on the issue doesn't quite cut it either because in the end he supported your big-disk panacea theory.

It doesn't matter how large your / partition is. If some program really goes berserk, it will spurt errors fast and steadily until your entire partition is filled up. If the partition is really large, it will take longer, but it fills up eventually. And you won't notice anything until the system begins to choke. You might not even have a chance to shut down cleanly.

You could keep an eye on a directory with cron and 'du -b /var' or something like that, but what if you spend some considerable time away from the machine?

That you've "never experienced that in over ten years on any Linux system" is completely irrelevant. I've never had a hard disk crash in over ten years using computers. Does that mean it can't happen? I've never had lightning strike my house and fry equipment. Does that mean it can't happen? Of course it can, these happen to people all the time. I've had programs fill up my partition twice. The first time around, it did bring my system down. The second time around I was wiser, had a different scheme in place and my system wasn't affected. I could investigate calmly and fix the culprit without any hassle.

In that second paragraph in my quote box above, you state just the opposite of the truth: if a separate partition (not /) gets full, the system does not get stuck. The system halts if the / partition is filled up. The system doesn't care so much about what happens to the other partitions.

I understand what you mean but my laptop love ZFS while booting with the non Forth based poor man's BIOS.
Actually ZFS is the best filesystem for any O/S that supports it, currently Solaris/OpenSolaris and FreeBSD (+ Mac OS X unofficially).
It removes the file-system/partition strong relationship which is the root cause of the issues discussed elsewhere in this thread.

i like my /boot separate because then I can point grub to the same partition, keep all my .configs/images/initrds in one place too. even across distros

for my 2c I'd put /tmp on its own partition too - as a desktop user this can fill up quickly if you don't know to check it - and having /tmp files fill up your / parition is just as problematic as /var/log.

i don't think thats exactly true. you can have a rough idea about how much software space you need (for /usr and /opt ) make small / , /var/log and /tmp partitions then the rest can be /home or whatever.

plus with dd or (easier) gparted you can move & resize later.

bottom line is that partitioning (like all of linux) is really about user preference. (glad we have the choice)