I have a 320 GB HDD, which is about 298 GiB, and Arch Linux will be the only operating system on the target laptop.

I read for almost 3 hours on Google about these and it seems that different partitions and file systems for a few directories is good practice; even according to the Arch Wiki.

Here is my scheme I plan to use based on my research:

Directory : Size : File System

Swap : 3 GiB : Swap
/boot : 2 GiB : Ext2
/var : 20 GiB : reiserFS
/home : 100 GiB : XFS
/tmp : 25 GiB : XFS
/usr : 100 GiB : JFS
/ : Remaining (48.x GiB) : JFS

Is that OK or is having a diversity of file system hazardous or slow?

Two Notes:
1. Size is a complete guesstimate. Suggestions here are very welcome.
(Not to interested in having one fill up, and not having the choice to resize it [xfs and jfs].)

2. I took from my research that each different file system does different things good, and different things not so good. So I though that by assigning them to partitions where their Pros are utilized, i figured I could get maximum performance and speed boosts, while keeping stable and well configured for a long time.
XFS: I came to think XFS is the best file system for dealing with lots of bigger files such as pictures, movies and music, so I chose it for my /home, because speed of writing/deleting and access time are important there. I think it's also good for /tmp because I download and move large files quite often.
JFS: With minimal CPU usage and ability to recover very well, I figured that would go nicely in / and /usr.
Ext2: For /boot, journaling is not needed and research would indicate this would make booting a bit faster.
ReiserFS: /var contains lots of small files, and reiserFS is documented to deal with those exceptionally well.
That is how I came up with this scheme. Suggestions welcome, but please explain why so.

Sorry if this is a problem, since I know I should wait at least 24 hours before bumping a thread.

Apologies, it's just that I was planning to install Arch tonight and I anticipate it will take me a while so I want to get up & going before I get too tired.

So, albeit out of character for me to do this...

Bump...

Please is there anyone that can give me a suggestion before I make these changes permanently?

For non-server systems I usually just make /, /boot, /home, and swap. I can't really find anything wrong with your scheme (although /boot and /tmp0 seem a bit bigger than they need to be -- I usually make /boot partitions 500 MB max and a few gigs for /tmp -- YMMV). However, Ireally don't think you're going to see thaqt much performance difference between the various types of filesystems unless you're running a file server or other high I/O systems. I've tended to stick with ext3 (now moving things to ext4) for stability and support. I've been liking ext4 a lot on my file servers lately, so you may want to consider it. IUt is still fairly new though, so make sure you have back-ups (good advice for any file system).

1 members found this post helpful.

Well, the limitation on this computer is that it's a netbook, so the CPU is a bit limited and the Front-Side Bus is really low ~600- Mhz

I did upgrade the RAM to 2 GB's and its got a good HDD.

I'm typing this on another computer right now as I blankly look at cfdisk on the Arch installer, so I appreciate your advice. Does the above information change any ideas about what you wrote or should I just go ahead and write it to disk?

That was so much appreciated.

Oh yeah, and of course I can only make 4 of those partitions primary. Which ones should be primary and bootable? I was definitely considering /boot and / as both bootable and primary. Would that suffice?

It being on a netbook doesn't change my opinion much, however if you have a solid state drive that would change things a bit. I don't think that make 300 GB SSDs yet (or if they do they're hideously expensive). From my experience, filesystem overhead stuff does not take that much CPU time -- orders of magnitude less than actually getting the data to and from the disk via the SATA interface. Even a 32 bit 800 MHz FSB is as fast as a 3 Gbps SATA link (at least if I'm doing my math right), so bandwidth to/from disk will still be the bottelneck for things that don't fit into buffers/cache in memory and the journal has to be committed to disk continuously. It's been awhile since I thought about this seriously, so take the above with a grain of salt, but the long and the short is that for standard desktop usage I haven't noticed much in the way of CPU burn for I/O intense ops (most of the time for these is spent in iowait) even on slow machines. So I don't think it will make much of a difference for you. Where I have noticed a difference is with large RAID arrays, and SSDs have their own sets of challenges that suggest different approaches (mostly, from what I've heard, to prevent wearing out the drive by writing too frequently, but I don't have any experience with SSDs).

1 members found this post helpful.

Ok, well I don't know if the above will change change the scheme too much, this is sort of a test anyway.

However as per your very appreciated advice, I'm going to lower /boot to 1 GiB and /tmp to 15 GiB and give them to /.

Only /boot needs to be bootable, right?

Or does the Arch installer take care of what needs to be bootable?

Most of the partitions you have listed are way too big, especially for a simple single-user system.

All /boot is needed for is to hold the kernel and initrd images, and the bootloader files necessary for startup. A few dozen MEGAbytes would be all you really need, but I'd personally say that a separate /boot isn't really necessary.

As for /usr, it holds most of the programs and libraries your system needs, but in truth that isn't all that much. Only a few big programs like OpenOffice really take up a lot of space, and that's on the order of a few hundred megabytes. My /usr drive holds, 4GiB on a heavily-loaded desktop.

Th size of /var depends some on how you intend to use it. If you plan to use it as a place to keep a lot of temporary data, then you'll want it big; otherwise it mostly just holds logfiles, temporary packages, program data and such. The /var on my above system generally racks in at about 1GiB, but can double or triple during certain large operations (see below).

/tmp is similar to /var, but it holds even more ephemeral data. You'll probably rarely need more than 5-10GiB though, unless you routinely work with super-large data sets.

Finally If you're moving things like /usr, /var, /tmp, and /home into separate partitions, then the / partition itself doesn't have to be very large at all, perhaps a couple of GiB.

When I partitioned this system years ago, I failed to give myself enough /var and /tmp space, leaving them as part of my 2GiB / partition. Still, the only time I have trouble is when I have to do a major update and apt wants to download a GiB or more of packages at once. So I have to break it down into multiple smaller updates. Some day I'm going to have to repartition to give myself some more room.

Finally, swap. There seems to be a never-ending debate about the best size of, and even the need for, swap. My personal opinion is that, if your system memory is 2GiB, you should have an equivalent amount of swap (assuming a home user system, of course). If you have less memory, then you should have more swap, and vice-versa.

I guess the way to think about it is that the total system files on a single-user system are unlikely to exceed 10GiB. Add in another 10GiB or so for temporary files, ~2 for swap, and the rest can go to /home.

There's no need to make any partition bootable on Linux. That's a legacy dos/windows restriction. The bootloaders on other operating systems are smart enough to boot whatever partition(s) they've been programed for.

So, you're suggesting I change the partition scheme to this:

/boot 500 MB
/tmp 10 GiB
/var 10 GiB
Swap 3 GiB
/usr 6 GiB ?
/ 10 GiB
/home The Rest? Like, 260 GiB?

Seems Home gets a very large partition. My current home has about 10 GiB!

I can do no better than to follow advice from someone with more experience than I, but, Well, that scheme shocks me a bit.

If this helps, this install will have the GNOME and X of course, compiz*, lots of music files and a few pictures, and probably a ton of programs, but mainly Google Chrome, Thunderbird, Bittorrent and the GIMP.

Sorry, it seems rather shocking to have such different advice.

I said that if /usr, /var, /tmp, and /home are all on separate partitions, then / itself can be 2GiB or less. It would have to be made correspondingly larger for any that aren't given their own partitions.

The total size needed for the entire OS is unlikely to exceed 10GiB system files (/, /boot, /usr) + ~10GiB temporary files (/var and /tmp). All the rest of your space can go to personal files, i.e. /home and/or whatever other partitions you may want to create.

So yes, I'd say the above partitioning scheme is pretty good, except for /, which only needs to be 2GiB. Actually, I'd probably also reduce /home itself to a few gigabytes, and use the rest to create an additional "personal storage" partition to hold all of your music, video and other miscellaneous files. This would make it easier to preserve those files if and when you ever want to reinstall.

Again, this is assuming a standard home system. Things would be different if this were a server or something.

As for why you're getting so much "conflicting" information, it's because it's not really necessary to break things up into partitions at all. A single large / partition is all that's actually needed to have a functioning OS. So everything you read is really just advice based on personal experience, with different people having different opinions about what's important.

My advice is to simply read as many of the various schemes and explanations as you feel you can stomach and try to understand the reasoning behind them. Then make your own decisions. Don't think of any single one as being definitive, including mine.

1 members found this post helpful.

A lot of the advice floating about is from systems administrators used to servers. They need /var and /temp to be on separate partitions because of the amount of data and traffic on them: you don't.

A /home partition enables you to re-install if it ever becomes necessary without over-writing your data, and the swap partition enables you to use the hibernate feature. That's all I'd bother with. A /boot partition is necessary if you use LVM, which again is really for servers, and an ext boot partition is probably safer if you want to use a different filing system elsewhere.

Filing systems like XFS may be very fast, but I doubt if this will show much on the sort of files you'll be handling. Most distros for desktop/laptop systems default to ext3, and I've always assumed the distributors know what they're doing.

1 members found this post helpful.

I agree with the other David. A lot of advice out there is based on production use. For home users, simpler is usually better.

There's really no need for a simple laptop to have half-a-dozen different partitions. I've already said that a separate /boot was unnecessary for a desktop, and /var and /tmp don't really need to be separate either--but you do have to ensure that the drive they're located on has enough space to handle occasional large loads. A separate /home however should be almost mandatory.

I intended to mention filesystem use as well in my last posts, but forgot. Again, KISS should be the operating principle. XFS and whatnot may have fractionally better performance in some circumstances, but they come at a cost of being more complex to maintain. Specifically, many of the common low-level access and recovery tools don't work with them. Ext3 is the default because it's reliable and because it has all the tools necessary for maintenance and recovery.

When I installed this current system several years ago, I was still fairly new at this and decided to use reiserfs for all my main drives, because what I read said that it performed "better". I now feel that that was a mistake, as it's limited me in certain ways and hasn't really given me any noticeable benefit. When I set up my second system I went straight ext3. And I'll do the same with this one when the time comes to reinstall it.

But as I said in my last post, this is just my advice. You're free to try out whatever you want.

Agree with that, although in my case, I find that around 100M is easily adequate for /boot. (If you need much more, it means that you haven't been doing your housekeeping and have many old kernels hanging around; up to you if that is acceptable).

I have no evidence that using so many file systems is either hazardous or slow (but then I wouldn't...I use ext2 for boot and something else (formerly reiser3, recently ext3, maybe next time ext4?) for everything else on the machine, so if it was a problem, I wouldn't know).

Note that for every filesystem that you use, you will will have to load the appropriate driver software, so the more that you use the more that you load and that may be a factor in memory-constrained situations, although, if you have what is, these days, considered a sensible amount of memory, it may not be.

My opinion is that you are overcomplicating things and that you won't see any actual advantage out of the usage of multiple (greater than two) filesystems, but, as I haven't tried it, how would I know?