Attention Linux friends (non-geeks may want to avoid the following post)

[gwalla]

So, I've built my new PC, and I'll be installing Linux* on it. But before I do so, I need to decide how I'm going to partition the drives.

I have three 250GB SATA-2 drives in here, which I'll be using in a software RAID array. My current plan is to partition them like this:

• /boot will be a RAID-1 array, so it can still boot even if a drive goes down (RAID-1 is the only RAID that the bootloader understands, because it looks identical to a non-RAID partition)
• "main", a RAID-5 array, will be an LVM volume group, divided up into a few logical volumes (mostly to make backing up easier, but also to allow for different mount options) and holding most of my data:
• / (root)
• /home [nosuid]
  
• /usr [nodev]
  
• /var [noexec, nosuid, nodev]
  
• "volatile", a RAID-0 array, will also be a volume group, specifically for files with short lifetimes:
• /tmp [noexec, nosuid, nodev, noatime, nodiratime]
• /var/tmp [same as above]
• /var/spool [noexec, nosuid, nodev] - since this won't be a server, /var/spool/cups will probably be the bulk of this directory
  
• Mozilla cache (mountpoint to be set later) [noexec, nosuid, nodev, noatime?]
• swap (18GB total, 6GB each) - I only have 4GB of RAM (4x1GB DIMMs), so this is more than twice what I'd need (going be the "swap = 2xRAM" guideline), but I may upgrade to 2GB DIMMs later on (that'd be 16GB, but that doesn't divide evenly into 3 drives)

The logical volume groups may contain some space not assigned to specific volumes, to make it easier for me to adjust and possibly add new volumes later if necessary.

The sticking points are these:

• How big should /boot be? I've seen suggestions of 10MB, 25MB, and even 100MB. I don't think I'll be doing any kernel hacking, so I don't think I'll need space for a bunch of spare kernels. What size would be safe yet not excessive?
• How much space will the temp directories take up, in general? I know /tmp should be larger than 4.7GB to allow room for DVD burning, but I'm not sure how much other applications will typically need.
• Should /usr be mounted read-only, and just remounted when installing new software? It may be more secure, but could also be more hassle.
  
• One suggestion I've seen is to make /opt a symlink to /usr/local (or vice versa), because they have the same basic purpose, but some apps use one and some use the other. Putting them together shouldn't result in any collisions, and may make it easier to back up. If I did that I may make them a separate volume on main (which I'd probably do anyway for /usr/local if I make /usr readonly, so I could keep it read/write).
  

Thoughts? Suggestions?

*Fedora 6, to be precise

Comments

[jfd62780.livejournal.com]

I tried Fedora 6; when it rebooted, "for the first time", it went to a screen mode that my monitor couldn't handle. x.x

[packy.livejournal.com]

One of the things I've been seeing lately is having /tmp not even go to a normal disk partition, but rather have it set up as a tmpfs partition so it can share space with swap. Googling provided a quick overview of the pros and cons of this approach.

I've never bothered making /usr read-only for a machine I do work on; I reserve that for special-purpose hosts, like firewalls, dedicated file servers or MythTV boxes. ;)

But I would symlink /opt to /usr/local.

[gwalla.livejournal.com]

Huh. That's certainly an interesting idea. I had no idea you could do that.

I'll have to look into that. Not only for /tmp, but also possibly /var/tmp and /var/spool (but not /var/cache or the Mozilla cache, since the point of those is to let the data persist).

[packy.livejournal.com]

See, I always thought that all the stuff in /var should persist. But then, that's just me. YMMV. ;)

[gwalla.livejournal.com]

I think /var/tmp files generally have longer lifetimes than /tmp files, but don't need to last between sessions (some admins set it to delete at shutdown like /tmp). /var/spool/cups and /var/spool/lpr are just for print spooling and don't need to last through a reboot. Files in /var/cache are just to hold the results of time-consuming processes to save time, and can be recalculated if lost. The Mozilla cache is similar.

What I'm concerned about here is how tmpfs would work with writing DVDs. I believe writing a DVD-R in disk-at-once mode requires a temp file the size of the DVD itself: 4.7GB, just about .7GB larger than my RAM. Would this thrash?

[packy.livejournal.com]

With 18Gb of swap space? I don't think so. It'll start writing to /tmp, and as it exceeds the amount of free RAM, it'll start paging out least-recently-used bits of /tmp to the swap space. Some of it will get written out to disk (like it would if /tmp was a regular fs), but some of it will stay in RAM, so you get a performance gain. It would only thrash if it tried to access random bits of the DVD image repeatedly, but writing disk-at-once doesn't work that way, does it? It should just dump data into a disk image and then read it back sequentially as it writes the DVD. Even if it makes several read passes on the disk image, it's not going to have to write them back when it pages them out because they won't be changed...

Of course, I'm not the expert on this. :/ It's just something I've seen done, and thought was cool.

[gwalla.livejournal.com]

That sounds about right.

Hell, if it doesn't work, I can just make a new volume for /tmp. LVM is nice like that.

I may still use a RAID-0 for those other volatile directories, though.

[gwalla.livejournal.com]

Hmmm...according to this (http://www.mjmwired.net/kernel/Documentation/filesystems/tmpfs.txt) the default size for tmpfs is half of physical RAM, and "If you oversize your tmpfs instances the machine will deadlock since the OOM handler will not be able to free that memory." Maaaaaybe I shouldn't be messing with this.

[shadesfox.livejournal.com]

Honestly, I've never been a fan of having a lot of mount points, especially on a not server system. It just seems to cause more problems then it solves.

Still, with boot I usually like to to make it 256 meg with ext2. It is far more then is ever needed for boot, but with how much space you have on your disks, will you really miss the 192 megs of space that could have been?