Hard drive for swap/tmp/var?
 

I'm building a new system, and I'm thinking of having a dedicated drive for the highly-rewritten sections of a drive.

That is, partitions for /tmp, /var, and swamp[*]. What should I look for in a hard drive for this? Are there any hard drive types/manufacturers that are better for this? And how large should these partitions be, especially given that this is going to be on a modern hard drive[+]?

I'm planning on starting with 2GB RAM, and may go up to ~4 (my motherboard will only support what it refers to as 3+ GB), on an AMD64.

[*] That was a typo, but it was too good to pass up.
[+] The smallest HD sold at (e.g.) Best Buy is 40GB. I suspect that it might be hard to find a hard drive smaller than, say, 20GB.

Since you have a lot of RAM, then hopefully swap won't be used much. You can get a nice boost in performance by avoiding the hard drive altogether for /tmp, /var/tmp, /var/run, and /var/lock. By putting these in tmpfs ramdrives, the hard drive won't be used at all unless those temporary files take up a lot of space (in which case the spillover will get offloaded to swap).

You can make ramdisk entries in your fstab like this:
Note that tmpfs ramdrives inherently start off completely empty. Any data within a tmpfs file system is lost when rebooting. Thus, it should only be used for directories where keeping data between reboots is not necessary (or even desirable).

But what about /var/spool, /var/log, and the rest?

I don't know what you expect to gain by putting those files on a separate drive. separate partition, yes. Maybe I don't understand some tecnicality, though.

After considerable experimentation, using Debian, I now format my 80 GB disks like this. All on separate partitions. I don't think that interferes with IsaacKuo's suggestion above. You could still edit fstab to handle those specific directories.

swamp, /var, and /tmp are high-traffic areas. If you get bad sectors, that's where you're going to get them. The points are that 1.) these might do well to be on a higher-quality drive, and 2.) it would be better to have all the bad sectors on one drive so that you don't wind up with an essential drive that has large sections that are practically unusable.

AFAIK, bad sectors can appear anywhere at any time, often due to overheating. To maximize hard drive reliability, the most important thing is keeping its temperature low. Multiple drives can actually harm reliability by restricting airflow and/or generating more heat.

If you're concerned about hard drive reliability, the best thing is to make sure the hard drive is getting good cool airflow.

If you are really trying to get every ounce of performance out of your harddrive you should first look at things like seek time and rpms. That will boost the performance more than anything.

Something else you can do is consider the shape of the harddrive itself. In theory if data is closer to the center of the drive it has a higher chance of getting to the heads faster. So how do you get data to stay towards the center? Well, the harddrive begins on the outside of the drive. This is opposite of a CD-ROM which begins on the inside. This means that according to what you think is written to the most (which is debatable) it should be the partitions toward the end of the partion table.

You say swap is written to more than other? If you are really gonna have 2 GB of Ram, do you really expect to use that much ram? I've got 768MB and I rarely, if ever, use the swap partition..... /var/? Depends what you're doing. Serving a lot of web pages from var? Ok. Most of your programs and librarys probably load out of /usr/. I would put home and usr and maybe tmp as the highest used (not in that order).

Well, speed isn't the issue. Reliability is.

For example, if I wanted a faster drive, I could get one of the new ones that has a flash RAM cache. But that wouldn't be good, because the flash has something like 100,000 erase cycles per block. This is more than CD-RWs, for example, but still less than a decent hard drive.

Let me also be clear about one other point. The issue is not how many times it is read, but how many times it is erased (or altered).

As I say, failure doesn't come from read cycles, but from write cycles. You don't typically alter the web pages that you are hosting on a minute-to-minute basis, do you? Looking at some of my logs, they're updated every minute or so.

I'm looking for some advice on how to find a drive that has enough resilience for highly-rewritten partitions.

Are you so sure about that? I thought it was head crashes, which can happen independantly of read or write cycles, because the platters are never physically touched during a read or write sequence. If you have a source to back that up I'll be willing to agree.

And if that were true then wouldn't something like your file allocation table get corrupted often because of errors from constantly being written to in such a small space?

Flash memory can fail due to the write cycles, but not magnetic hard drives.

The original poster may not be aware that by default, POSIX file systems (including ext3) write to the disc for every read access, and journaled file systems like ext3 constantly write to the disc even with the POSIX-compliant "atime" feature turned off. By default Linux is CONSTANTLY writing to all mounted ext3 partitions!

This is why you have to be careful how you mount flash memory. For removeable thumbdrives and digicam memory cards this isn't a problem, because they're usually formated in FAT--a file system which is neither journaled nor POSIX compliant. With FAT, the only reason to write data to the partition is if a file is actually being created/deleted/modified.

Huh. I could have sworn that that was one of the main factors that would cause wear and tear on your disk (bad block here or there, that kind of thing). I do know that you are constantly (well, occasionally, but at a constant rate) losing blocks to wear and tear and that hard drive manufacturers put in extra sectors to compensate.

Ah, well. So how large should these partitions be? I'm uneasy about having a system with no swamp, and what should I allocate for /tmp and /var?

Flash drives do have a ceiling on how many times they can be safely re-written, but at least as I see it regular hard drives do not. Hard drives were *designed* to allow their contents to be changed at will, and all hard drives are subject to failure over time, but only because that's just the nature of hardware. Nothing lasts forever. Regarding the comment that "ext3 systems are constantly writing to the disk", I'm not sure that's accurate. Ext3 filesystem do record the timestamp of the most recent access (which has to be stored somewhere), but that data will only get written once the write buffer gets filled. So, Yes, in a certain sense, information is always being saved to the disk, but literally, No, the disk is not in a state where it is performing a Write operation 24/7.

Anyway, with regards to your "swamp" (heh, good one) partition, with 2G of RAM, it's unlikely that you'd ever really have much need for the swamp. Give it 256Mg or 512Mg, but otherwise you're just wasting disk space. Swamps only are needed when the load on the system exceeds your physical RAM, and the system is forced to write memory pages out to disk. The more RAM you have, the less likely that scenario becomes. Personally, my guideline is that if you have at least 256Mg RAM, a 256Mg swamp is all you need, because most typical desktop systems do not exhaust all 256Mg RAM. The ancient "swamp = 2X RAM" recommendation dates from the late 90's, where having 8Mg or 16Mg RAM was considered pretty respectable, and it was relatively easy for your system load to consume 100% of RAM, thus making swamp a critical consideration. Most home PC's today are more orders of magnitude more powerful than what their owners use them for (eg, nobody really needs 1G of RAM and a 3Gz CPU if they only use their PC to check Email, visit MySpace, and listen to their mp3 collection) and as a result the importance of swamp has diminished.