all drives will have a mixture of small and large files on them, so I am wondering if i should go ext4 and tweak indoes for the /home folder on laptop and store folders, or use xfs for server and main pc ?

I know there is no hard and fast rule to this and you can set them anyway you wish, and maybe tweaking the settings will give no performance increase what so ever, but i would like to make the partitions as space efficient and as fast as possible.

Currently I am about to re-do all my systems to try and tweak as much performance out of them as I can

OK then you are ready to rethink your entire partition scheme as well ?
Of course you understand that your freedom in tweaking largely depends on how much dedicated your partitions are.
You could think of dedicated /tmp dedicated /var with portage's tree on it / dedicated /usr/portage/distfiles... and so on.
While you are at it, may I also suggest you to have a look to a not widely known rather new feature of ext4 filesystems sarting with 3.8 : Ext4 embeds very small files in the inode which might well influence your choice.
Of course, I do not mean one should adopt this form of storage, I simply mean that the question is to be considered when thinking about tweaking ext4.

When your choice is done, please come back for tweaking suggestions._________________

Currently I am about to re-do all my systems to try and tweak as much performance out of them as I can

OK then you are ready to rethink your entire partition scheme as well ?
Of course you understand that your freedom in tweaking largely depends on how much dedicated your partitions are.
You could think of dedicated /tmp dedicated /var with portage's tree on it / dedicated /usr/portage/distfiles... and so on.
While you are at it, may I also suggest you to have a look to a not widely known rather new feature of ext4 filesystems sarting with 3.8 : Ext4 embeds very small files in the inode which might well influence your choice.

OK then question 2... and maybe the most important : Are you ready to rework all this and tune everything knowing that, at best, you can expect a +(5-7)% diskspace and a theoretically certain but... almost not-measurable performance gain ?_________________

Yes as I am bored, and have depression, and need to do something to keep me occupied :p

I could leave it the same, I just thought I would seek advice on it before I did it

I suppose now it comes down to which FS for home and the storage drives, seeing as there are movies, images and music on there_________________I know 43 ways to kill with a SKITTLE, so taste my rainbow bitch.

OK then, this is what I do for a daw.
Do not necessarily do the same, what follows being more a collection of ideas for tweaking.

1/ Use cfdisk from util-linux for partitioning !
cfdisk because it allows you to easily maximize disk usage on partitions. (Expect the equivalent of a track...)
OK, fdisk automatically maximizes but then... you just do not realize your win and cfdisk additionally gets a highly depressive nice 1980s curses interface...

OK then, a little bit more seriously...

2/ /boot
I made an ext4 / 32Mb.
You'll notice a huge inode_ratio (You keep there essentially kernel bzImages that is to say not many files around 3Mb each)
Not many files => dir_index = no
No huge file => huge_file = no
Big files => Blocksize = 4096
inode_size=128 because I do not make use of any particular extended attribute and don't care nanoseconds timestamps.
I will never ever have to resize it => resize_inode = extra_isize = no.
(Note that has_journal can seems surprising for a boot fs but, in my particular use case, I play a lot with this partition I never mount read-only.
Any standard user mounting this partition read-only can avoid journaling here.)
Follows is the corresponding entry in my /etc/mke2fs.conf

3/ TMPS
I made a general tmp purpose partition on which I 'll mount-bind /tmp and /var/tmp (14Gb)
I made it ext2-like because I do not need journaling.
More standard inode_ratio because it will host about... I cannot tell precisely what at mkfs time...
Id above, don't care of xattrs, huge_file, resizing...
Could host a big amount of files => care about dir_index.
Follows is the corresponding entry in my /etc/mke2fs.conf

4/ /var (4Gb)
In addition with all traditional logs / queues... I use var to store the portage's tree as well as my local overlay : Huge number of small files.
=> Impact on blocksize and inode_ratio.
Same as above for the rest apart from journaling.
It is currently : 21% blocks used and 40% inodes used. => Maybe I should think about halving the inode_ratio...

5/ root (96Gb)
Well... since I do not want to bother with initramfs thingies... my formerly independent (/usr & /opt) joined /...
Same observations as above.
It is currently 29% blocks used and 17% inodes used.

6/ home (334Gb)
Well... same observations as above... I never imagined that I would have to host so much big files onto it...
Despite the rather huge inode_ratio, it is currently 25% blocks used and... 5% inodes used... only. !
Will think about twicing the inode_ratio whenever I reach your depressed state... and want to spare a couple of sectors...

think I should leave it as is then, still going to reinstall the systems, but this time use clonezilla to image them so I have a fresh image and system should I ever need to re-install due to user error :p

Thanks for the help and advice _________________I know 43 ways to kill with a SKITTLE, so taste my rainbow bitch.

In case anyone (else than the OP ) is interested in tuning his fs, I realize that I did not document the "extent" feature I set for every fs apart from the tmp.
This feature is set in order to enable the user to run the e4defrag defragment utility.
Of course, it makes no sense for tmps._________________

hmmm, didnt think that was stable yet, and I havent looked at the mke2fs.conf in /etx to see if it is a default setting or not, ah well_________________I know 43 ways to kill with a SKITTLE, so taste my rainbow bitch.