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

[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.