Hey guys, I'm migrating from an old FreeBSD server to Debian Linux and wondering how I should set up the new drives in the new Debian system. In the FreeBSD system, there are six 65 GB drives. The last four are for /mail and user homes directories (/home is not used) and the first two are partitioned for the OS with the following usage stats:

0.2 of 21 GB for /
xx of 10? GB for swap
14 of 19 GB for /usr
2.9 of 15 GB for /tmp


8.1 of 28 GB for /local (/usr/local is a link to this)
4.6 of 19 GB for /var
2.4 of 9 GB for /soft (optional)
3.5 of 9 GB for /scratch (optional)

I was thinking for partitioning for Debian with the following settings and options:

80 GB for / (4% reserved, set as bootable)
13.6 GB for swap
150 GB for /usr (1% reserved)
50 GB for /tmp (2% reserved)

100 GB for /usr/local (1% reserved)
50 GB for /var (2% reserved)
50 GB for /soft (2% reserved)
93.6 GB for /scratch (1% reserved)

I'm assuming FreeBSD uses space in mostly the same way as Debian will. Should I be concerned about not having a separate partition for /opt /srv or /boot? Anything else I should be concerned about?

Thanks!

Hi davidstvz,

I'd probably bo for a /boot if I where you. As for the rest of the partitioning, I can't think why you'd need assign so much space to any of these partitions.

For swap, the norm (although it might have changed now) was 1.5 times the RAM. I'd say, start small and if you need to grow, just add more swap.

As for the rest, I'd strongly consider LVM. That way you can add space when and where it's needed and don't lock yourself into a specific setup. Debian will help you do that at installation time.

Maybe a RAID5/6 on the disks would be an extra bonus unless you need all the space.

That "norm" for swap was true 15 years ago when you had 64MB RAM. Now, assuming a low end of 1GB RAM, you don't need much, if any, unless you're hibernating. Or know you're doing a lot of RAM-heavy tasks (in which case you should invest in some more RAM to save your time and sanity). On my servers (384-512MB RAM) I give them 128MB swaps; on my deskop & laptop (2GB RAM ea.) I do ~1GB RAM because I hibernate, and with compression and closing programs (most of them Internet-enabled) before I hibernate, my RAM fits in the space.

What are the benefits of a separate boot partition? I expect that will be written for me automatically and left alone.

The server has 16 GB of physical memory so the swap will likely never be used (we're not running any large databases or anything).

I already plan to have the system run a RAID 5 for every logical drive (18 drives total, 3 drives per logical drive). The 300 GB size comes from combining three 150 GB drives in a RAID 5 config. I could potentially run a large RAID 6 in place of any two logical drives for the OS portion. My only concern here is performance. Perhaps the system would perform better running on two RAID 5's than a single RAID 6.

I have the same concern for user files. If performance wasn't an issue, I would definitely consider running two RAID 6 arrays of 600 GB each.

EDIT:

From what I'm reading, RAID 6 is slower at writing to begin with. But I'm also wondering about the following situation:

If I have two separate RAID 5's with a single partition each: /home1 and /home2

vs. a single RAID 6 with two partitions for /home1 and /home2

Will the RAID 6 performance significantly worse? That's both tricky to imagine and test.

Also, any tips on file system to use?

I read about a guy having write problems using almost the same hardware (using SATA drives instead of Serial SCSI basically). He improved write speed greatly by going from ext3 to JFS file system. Maybe I won't have a problem with SCSI drives.

The 'rule' always used to be quoted as twice the amount of ram; the trouble is, blindly following any rule like this was always nonsense. The less ram you've got, the more swap you'll need, so multiplying the ram by some constant is not going to be workable in every case.

That said, if you have a sensible amount of ram, almost any number will work.

Well, if you never use it, you don't need any, but I'd tend to put in something small like 2-4 G, so that if something does go pear-shaped, performance degrades (and you have a chance of killing processes to recover and/or doing diagnostics to see exactly which processes were the cause) rather than just have it hit the wall.

Sorry, too difficult. The performance of various filesystems is heavily dependant on the exact nature of the workload, and I can't even guess what's best for yours....but

There doesn't seem to be any need to use anything other than ext2 for /boot, unless you are really scared of the extra time for an fsck on a small volume.

From a performance p-o-v, what you really want to worry about is where most of your traffic goes. So worry less about 'volume x uses 100 G' than 'volume y has a peak data rate of 30M per second'.

Organisation (if you update the kernal, it makes things slightly clearer, and, provided you check when you do an kernel update you should never get a nasty 'out of disk space' error) and the machine should boot. If you do something 'clever', like put the kernel on a partition that needs to load a driver before it will work, the boot process cannot work until the driver is loaded and the driver isn't loaded until the boot process has got beyond a certain stage. This is not where you want to be and it is easier just to do it right and not worry about it.

I didn't quite understand all that, but I'll separate /boot its own partition all the same. How much space should it have?

The majority of IO ops will be going to email here (normal delivery + spam and virus checkers). The rest will be users randomly accessing files (programming)

A couple of hundred MB would be reasonably generous, and if, every time you install a new kernel, you make sure that there is space for at least one more, you shouldn't have problems. Basically, its not an issue that's worth getting awfully worked up about.

I can only say sorry, I tried to express things as simply as possible, but its not exactly a straightforward issue.

.
Turn off atime anywhere you feel that you don't need it (you've not asked about this, but its probably the best performance advice I can give).

There is a degree of trade-off in the journalling filesystems between safety and speed, and I asssume that in this application you want safety above all. Obviously you might feel that there are some volumes on your system that you feel that you can be more relaxed about than others.

I assume that you don't have power going down randomly (UPS) which reduces number of times that you test the extra security that journalling provides.

Reiser used to be my performance advice for an fs seeing lots of small files, but reiser 3 is a dead end as reiser 4 probably will never see a formal introduction. Ext4 is a bit difficult to recommend for a production server just yet, as its a bit immature, although, in practice you would probably have to be unlucky to have problems and, if extents are used, can provide better perfoprmance than ext3.

I think that pushes me towards ext3 as a general-purpose fs and to only consider xfs/jfs if there are special requirements, for instance very large files. (I hope BTRFS will be my recommend at some time in the future, but if Ext4 is a bit immature, you don't want to hear about btrfs yet. I believe, however, that there is a planned migration path from ext3 to btrfs, but there may or may not be one from ext4 to btrfs.)

Note also that as the file systems become more advanced, the potential for altering performance by altering exact config details increases, so it is difficult to do an 'apples to apples' comparison and benchmarking becomes difficult to perform (lots of combinations of setup parameters) and interpreting benchmark results is even more fraught. And you can find some benchmark for each fs that makes it looks good, but how well that corresponds to your usage profile is unknown to me, and possibly to you too.

Yes, I'll have a UPS on this thing before I roll it out. I'm going to do a few tests before I commit to a file system and partitioning scheme. I'd love to use RAID 6 if I can tolerate the performance hit.

By the way, the old server is FreeBSD and uses UFS for its partitions (mounted with no special tricks, so no journaling).

Speaking of UFS, I'm not expecting any problems moving files from the old UFS file system to whatever I decide on. If that's a naive assumption, please let me know

After some thought about how much space I really need for various things, I decided to go with RAID 1's and RAID 1+0's for the best security and speed. Thanks for the advice guys; just what I needed.