Sequence of partitions / mount points
 

Hi, I'm wrecking my brain to figure out the best partition layout for my linux installation which I'm about to have on my laptop. Having read numerous articles on partitioning in linux I've gathered some ideas, still there was no let's say a clear explanation as to the sequence the mount points should be arranged on the disc...What I have in mind is to use a single disc space as efficiently as possible considering the head travel. The pc is a laptop, 160GB HDD and will be used as a normal desktop with some simple sound processing. Distro Linux Mint 10. I'm planning to have such partitions and all will come after a Win7 installation:

/boot -> some write it's not necessary in dual-booting, some that it's good to have for security
swap -> with 4GB of RAM i don't suppose i'll use it
/
/usr -> programmes are there, considerable usage?
/temp
/var
/opt
/home -> the largest one at the end

My idea is to have the most heavily utilised partitions close to each other so the head doesn't move for large distances. The placement also makes a difference as the closer to the inner rim of the disc the worse performance.
I'm also not sure about the sizes. Read posts with recommendations but still judging by installations on a different laptop and virtual machine e.g. 5GB for /opt is a bit too much as there's almost nothing in there. Certainly /usr fills up, /var too from what I've observed. / also has scarce data in it so I'm wondering if giving them e.g. 5 gigs each won't be a waste of space resulting in greater head travel.:confused:

Any ideas most welcome! :hattip:

Wow! I think that you're going a wee bit too deep. The guys who put distributions together have probably thought about all this so assuming that you've got your Windows 7 partition and another free one on the disk I'd do the install and when it comes to partitioning say "use all the free partition" If you must customise, I'd only have three partitions; /, /home and swap where / would also contain /usr, /etc, /bin, etc.
Suck it and see, if you don't like it you can always re-install. :D

Play Bonny! :hattip:

We all experiment with this at some point, it's ok if you want to do it as a learning exercise, but the truth is that if you can't think of a reason why you need this and you can't explain it with your own words, then the chance is that you don't need this degree of granularity at all.

Well, this enhances security because you can mount it read-only, however, it's also true that if someone gets root access to your box then no one will be stopping him from remounting it read-write to install a modified kernel and/or an initrd with a rootkit on it, etc. etc. etc. The main advantage of a separate /boot for a desktop user comes when you want to share the same kernel(s) across many different distros.

Having a small space dedicated to swap never hurts, but you can just create a sparse file on your root partition anyway. Having a partition for this nowadays is not necessary, nor does it provide with a better performance of anything like that.

/usr is probably the biggest thing (by far far far) that will live in /. For a desktop user there's little sense in having a dedicated partition for /usr. If you can't think of a reason yourself, then don't do it. It will only make your life more complicated. But, if you decide to do it, beware that / should be very small, otherwise you'll be wasting space uselessly.

Some users separate this one to avoid fragmentation problems, but, as I see it, fragmentation is hardly a problem in typical linux fs's unless you are doing something very specific. Separating this partition in any case could have side effects, since some programs could fail to run if they are short in temporal storage space. Most of them can be configured to use some other location though. Oh! and it's "/tmp", not "/temp".

Unless you are running a web, db, spool or mail server (dedicated server) you probably don't have a use for a separate /var.

In most distros, this would be a dedicated partition to install just flash and opera, and little else. I'd really skip this.
/home -> the largest one at the end

After having had my own doses of this I'd say this really doesn't change anything. For a desktop setup, a typical one, it suffices to have a separate / and /home. If you want, you can create another partition for /tmp, and link it to /var/tmp. For swap, just create a sparse file and mkswap it. And if you are going to piece together a home server, separate /var to ease backups.

Why would you stick Opera in /opt?

It's just the place where most distros put this kind of stuff, like proprietary (non-OSS) programs, just like opera and flash. You could put it elsewhere, I am merely describing the scenario, and telling you why making a separate partition for /opt in a desktop machine makes no sense.

Personally, I would place stuff handled by the native package manager in top level '/usr' and stuff that is not handled by the native package manager (i.e. hand compiled or handled by a secondary manager, e.g. paco) in '/usr/local' as long as it conforms to the rest of the standard layout (e.g. having bin/, lib/, share/, etc. sub directories), and (my own personal criteria) has a good method to uninstall. This is how the FHS seems to imply it should be used:

http://www.pathname.com/fhs/pub/fhs-...LOCALHIERARCHY

"The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr."

Obviously 'system software' would be stuff installed by the native package manager.

For me, Opera (where no native package is available) falls into this camp ( and yes it is shareable). The other advantage of installing into /usr/local as opposed to /opt is that on most distros Opera will be full integrated with no further effort by the user. By that I mean you will not have to adjust $PATH, $MANPATH, XDG settings, etc. for full system integration. You can just run Opera, use 'man opera' or get desktop integration (Desktop Environment shortcuts, MIME setup, etc.) with no extra work.

I would only use '/opt' where a package does not conform (often the case with apps ported from other OSes) and/or is large and unwieldy to remove from '/usr/local'.

Yes, we all know there's a standard. Most distros do interpret it as they wish though, otherwise /opt would be empty 99.9% of the times, which it's not.

I never spoke about installing things by hand. This is something that will happen (or used to happen until recently, I'll say in case something changed in the last few months that I am not aware of) on many mainstream distros. Not that Gentoo is mainstream, but you can take it as an example of a distro that will install proprietary stuff in that dir:

This was everything created and set up via the package manager. The native tool this OS has to install software. Most PMs will install one or another thing into /opt on most linux distros, as far as my experience goes.

Again, as said above, I am merely describing a thing that happens, I didn't invent the standard, and I didn't invent Gentoo nor any other distro either. This is deviating from the original purpose of the thread anyway. I only wanted to give my opinion that using a separate partition for /opt is not smart.

Also, and going back to the FHS, the points about shareability and fs isolation are not too relevant for a desktop user, as it's mounting /usr "ro".

That is achieved by putting almost everything together in one partition.

The physically first partition(s) have higher performance. Maybe you want the Win7 installation to have the faster portion of the HDD. But if that is not what you want, find a way to have Windows physically later on the drive (physical position doesn't necessarily match installation order).

I would leave everything other than swap and /tmp together in one / partition.

/tmp is more efficient as a tmpfs rather than as an ordinary partition. Doing /tmp that way may increase the need for swap. Having some swap anyway is a good idea. Plan for both when you decide how much swap to allocate.

The fact that you can't easily predict the best size for each is one of the main reasons that splitting them will result in both wasted space and extra head travel.

Your available disk space is low enough that you ought to give some thought to correctly sizing swap (including /tmp as a tmpfs). On a desktop system with a big disk, it is easier to just give swap more than it ever might need and not worry that doing so wastes a couple GB of disk. In your case, you probably want a more accurate estimate of /tmp needs in order to size swap. But for /boot, /usr, /home, /var, etc. even with a lot of effort toward good estimates of the required size you would still be wasting more space than you should for no actual benefit.

One more reason not to waste space in a swap partition. Use a sparse file, try, then adjust it. You can easily change the size of a sparse file, while toying with partitions is always risky. The kernel will map the physical space and bypass the fs anyway, so there's absolutely no reason to use a partition rather than a swap file in this scenario.

thanks for your insights. It seems more reasonable to have a simplier filesystem for normal desktop use. On the other hand the idea of the filesystem spread across +120GB is somewhat questionable to me...

The concept of shortening seek time is worth considering, especially in dual HDD configurations. Having 2 spindles reading / writing the requested data at the same time would be definitely advantageous. I'm wondering how would this be achieved in linux.

NTFS by default tries to squeeze data as close to the start of a volume as possible thus creating fragmentation problems. Correct me if I'm wrong, but still, defragmented data should be better accessible with shorter seek time on an NTFS volume. From what I've read a linux filesystem will try to spread data evenly throughout the volume hence leaving a considerable amount of space for files to grow or be easily moved, preventing fragmentation. In this case if I have a defragmented 30GB NTFS partiton filled with 5GB of data the head will call whatever it needs from the beginning of the partition finding the placement of files in the MFT (also at the beginning of a volume). If this were linux wouldn't this data be spread throughout the whole partition? If so the head would need much more seek time to call files which are far from each other.

source: http://geekblog.oneandoneis2.org/ind..._defragmenting

"A linux file system scatters files all over the disc so there's plenty of free space if the file's size changes. It can also re-arrange files on-the-fly, since it has plenty of empty space to shuffle around. Defragging the first type of filesystem is a more intensive process and not really practical to run during normal use.
The cleverness of this approach is that the disk's stylus can sit in the middle, and most files, on average, will be fairly nearby."

The above article states that it's beneficial that linux spreads the files more or less "in the middle" so the head can retrieve them starting from the middle on average. What about if we have 100GB of space for this retrieval? Won't it be too far apart so to speak for efficient seeking? I imagine the head running across the whole 100GB chunk of the platter in a fairly random logic. I know that the information about the placement is located in something called a "superblock" but still it's a mistery for me how would scattering files across a large space be beneficial speedwise?

It's definitely a good idea to divide the system partition from programmes in Windows and put on separate disks,preferably at the front. Big gain from:
a) smaller load for the system partition
b) 2 discs working simultaneously when calling files which reduces latency
c) utilising the outer zone which has best performance
d) easier maintenance of a divided filesystem

Would there be a similar benefit from separating / and /usr (maybe some other) and putting on 2 different disks? Doing this the filesystem, data and programmes could be read independently to a certain extent increasing access times. I'm not taking into account some special needs resulting from e.g. a dedicated mail server or sth similar. HDD performance only in more or less "standard" operation.

Regarding the swap partition I incline towards what i92guboy said. When I tested the system by opening all apps I have (no VM ware though) it wasn't even close to the amount of ram and swap was on 0% usage. Maybe a file which I can modify in size is more beneficial unless someone uses vmware or video / sound processing a lot.

Long post :)

If anyone has some experience with spreading mount points over multiple discs please write.:)

If you really care about performance over size, use those drives to piece together a RAID with mirroring capabilities. The redundancy will effectively double your performance 100% of the times (assuming your hardware is up to the task, of course). Partitioning won't ever do that for you. Even more, considering that you will put the OS in one disk and the data into another, and that you usually open a program, then load the data (a lineal sequence), you are probably not going to notice that kind of improvement you are looking for. The kind of improvement you can gain from this is the same kind of improvement that all the linux users get for free, and it's due to a thing called "i/o scheduler". Same goes for different partitions in the same disk.

I don't think so. 99.9% of your OS is into /usr. You'd be putting a few MB's elsewhere in any case, that's not going to help improving anything. To get some (marginal) benefit from this you'd need to distribute the subdirs into /usr on different disks, assuming that the bus mastering in your motherboard actually works, which is quite an assumption sometimes. This is even more true nowadays that some distros user tmpfs for /tmp, which means that it doesn't reside in your hd, but in your virtual memory (that can be whatever depending on the moment you ask).

I can't say I have experienced any gain from this in desktop machines. After years of testing my layout for desktops is usually /, /home/. In my main desktop I use a separate /var because I use some servers and I like doing backups the old and easy way. swap is a file.

I don't say that more exotic layouts don't have a use, I just think that the hassle and limitations that such a scheme puts on a desktop are not worth the trouble. But, it's just my opinion, of course. It might even change tomorrow ;)

You will probably have to test and decide yourself. :)