They are personal files. You might not be aware that *you* created them, but so you did.

If your home partition doesn't mount, having kde is not going to hep you fix the problem, you will need to be root to do so, and guess what: root doesn't live in /home, but in /root, for a very good reason. You are trying to solve a problem that already has a solution, that's why /root is /root and not /home/root.

That's not a fact. That's your personal appreciation based on your personal experiences, which obviously have not been good. Which doesn't mean that the formula doesn't work for a lot of people in both desktop and server scenarios. They all can't be wrong.

I am very scared now, and also a little dizzy from trying to follow the technicalities. And yet i have to thank you guys for transforming this post into a very useful reference guide to partitioning.

I was under the impression that logical partitions are necessitated only when the number of primary partitions exceeded four, and so their creation somehow detracted from the performance.
Also, i thought that renaming them in the correct order would naturally place them at the proper sections of the hard drive for optimum contiguity and access speeds. I realise now that these were notions formed due to an uneducated reading of too many views on the subject.
For eg. i read somewhere that swap should be the first partition, /boot is best formatted as ext2 for greatest stability and quicker fscks, and should be the next partition, /home should be closest to / for maximum read speeds and ext3 for stability, and finally that /(root) should be the last partition and best formatted as Ext4 to take advantage of it's greater write(or was it read?) speeds,(because hopefully, when the next edition of Linux Mint comes out, all the 'bugs/instability' in the format will have been ironed out.

So where do i go on from here? And just one more question if you please, i will not pester you after that; if you will look at my screenshot, the mount point for my data partition, /dev/sda7 is /media/data. Does it mean that when i install a new release on my /dev/sda5, it will get wiped out and replaced with a blank /media? If you say it will be untouched i would be happy to retire and sleep soundly tonight.

It is *true* that once you reach 4 partitions, the only way to go above that number is by using logical drives. This is due to the MBR-based design. The MBR is very finite, only 512 bytes. From byte 446 to by 510 (64 bytes) it's stored the info about the four possible primary partitions. There simply isn't any more space than that, unless you want to break the MBR standard (and consequently, break most bootloaders, OSes and partitioning tools, which will expect a standard 512 bytes master boot record).

The solution to this is define one of these primary partitions as "extended", which is nothing but a primary partition that can hold additional partitions inside of it.

There's no performance penalty in using a logical drive. A partition or logical drive is nothing but a finite space in between two positions of the disk. Nothing else. The rest is just a semantic question.

The performance is going to be the same, regardless if you use a primary partition or a logical drive inside an extended partition. The placement -physically- will only depend on the order you create them and their size. There's no special place on the disk for primary or logical drives.

The throughput is usually higher on the part of the disk that's closer to the borders, rotating at the same speed (not that that happens always) the head will read a bigger surface when it's closed to the border than when it's in the center. Some, some people prefer to create the swap space before anything else. In any case, this is going to be something marginal. The drive adjusts the speed so the differences nowadays should vary very little in any part of the disk. It has nothing to do with primary vs. logical. If there are only logical partitions, then hda5 will be your first partition and it will be in the same exact place that hda1 would live if it existed.

Faster fsck's are a thing of the journal, so it's ext3 and not ext2, which hasn't journal. However, being boot usually a partition or around 100mb or so, you are not going to notice any speed up or slowdown no matter what fs do you use. Both ext2 and ext3 will work with any current bootloader, so compatibility is a non-issue either.

Using one or another fs is just a matter of choice and tastes. I am not going into that because it always ends in a flamewar. I'll just say that ext4 is not as well tested as ext3. Ext4 has only recently been included in the official releases of the kernel, it hasn't given me much headache, but I'd still stick to ext3 when stability is a must. About performance, well, you can find a benchmark for any fs you like "demonstrating" that it's the absolute best. You only have to be receptive so it can convince you. So, in terms of benchmarking, ALL the OSes are supposedly the better, faster and safer ones, you just need to do the correct benchmark to demonstrate that for your fs of choice

Well, a couple of things. First, the mount point is irrelevant, it can be /media/data, /home/ftp, /foo/bar or whatever.

Second: *what* partitions will be touched will depends only on what do you do when installing a new distribution. having hda7 as a separate partition doesn't make it invulnerable. You are the one that, when installing, have to be alert, and instruct your installer not to use any automatic partitioning "feature". You need to instruct it to use sda5 for /, sda6 for swap, and to make sure that sda7 is not being to be formatted by the installer.

If you select it to be used as / then nothing will stop the installer from formatting it of course. It's doesn't matter if it holds your thesis or your better savegames.

Thanks for that assurance, but i thought it was understood that we were discussing manual partitioning and not the guided variety, and that i hoped to install the new release as / only on /dev/sda5, leaving /dev/sda6 and /dev/sda7 well alone.

(about my earlier remark that "unreliability is inherent in a system with many small partitions.")

Of course it's a fact. If a filesystem fills up over time, with respect to using up 100% of available drive space, the most efficient and reliable scheme is to have one partition. This is obviously impractical, but the next best thing is to have a minimum of partitions.

The OP created a scheme with lots and lots of partitions, and this thread started with my advice to avoid so many partitions. This is sound, time-tested advice. Choosing a scheme with many partitions must be weighed against the fact that it is less inherently reliable than one with fewer partitions, with respect to the issue of inaccessible, orphaned drive space.

If a system's drive begins to fill up, the only scheme that can maximize drive use before problems begin is one with a single partition. More than one partition may be necessary, but it is less efficient, because orphaned drive space is a virtual certainty.

Why do you think we have the present memory scheme? Instead of partitioning memory as we partition drives, we have elaborate safeguards to prevent a process writing where it shouldn't. The advantage is obvious -- in extreme cases, all system memory can be accessed before any problems begin. Having a single large memory bank is the only way to assure this outcome.

Goose, gander.

I get that now, but my primary objective (even though i went a little overboard with it) was to provide for the installation of a new and improved release every year or so--having this luxury just by virtue of being a Linux user--while at the same time retaining the separate data/home partition. You must agree that this advantage far outweighs the marginal loss, of efficiency and a few megs of orphaned drive space, that may result in having a separate partition. Of course, you have permanently rid me of those grandiose partition schemes as far as my present requirements are concerned, but i just have to insist, even with my limited experience, that a data partition is a must if the aforesaid objective is kept in mind.

Like saying that the best house is the one that has no walls. That might be true for one person, but not for most persons. "Unreliable" is a strong word for this, I think. A partitioning scheme doesn't make the system unreliable. With that criteria in mind a system that has a single partition that's 99% full is equally "unreliable". Adding some GB's of storage space before the point that your programs will start failing is like pretending to have fixed a memory leak in your programs by buying more ram

The right solution is a good planning as with everything in life. If you plan taking into account what do you have and what do you need to succeed, then things usually go ok. You can as well use lvm to make things easy in the future when you need to redo your scheme or modify it.

This is if you define "efficiency = storage space". There's certainly more than one scenario where having separate partitions is more efficient in other regards. And even when we speak about storage space, having more than one partition can be more efficient. Just think of an fs with lots of 500 bytes files (Gentoo portage, for example). On a regular fs with a standard block size this will take up to 1gb, on a separate volume, it can be stored in less than 200mb with a lesser block size, which can also be formatted with enough inodes to contain all the 140k files that conform portage). So it certainly makes sense to have a separate partition for portage, overall taking into account that these files are erased and written very frequently because they are the package database for Gentoo.

I understand what you say though, and it's a limitation of the current fs's. brtfs is supposed to solve this problem introducing the concept of storage pools, just like zfs on solaris. I really long for the day that it's mature enough to use it on my servers.

Found a Remastersys .deb package, made a full back-up custom iso, reinstalled. Look how neat it looks! That's one awesome tool by the way.
sade@sade-desktop ~ $ sudo fdisk -l

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xed122b18

Device Boot Start End Blocks Id System
/dev/sda1 1 243 1951866 82 Linux swap / Solaris
/dev/sda2 244 17021 134769285 83 Linux
/dev/sda3 * 17022 19457 19567170 83 Linux
sade@sade-desktop ~ $