a non-slackware question that can (probably) be solved by slackware
 

Hello everyone!
Ahead of the question let me warn that this is a hardware question that is out of context to the slackware subform. BUT since slackware is so flexible and slackers know their hardware. I'll go ahead and ask here.

Thing is, I have a hardware for data storage. But in the office we also work by opening files directly on this file server. The file server is run by an Atom Intel processor. (Who thought of putting a laptop processor in a file server!? and who decided to buy this piece of equipment???!).
At any rate, this is the situation now and while I could setup a fresh slackware server with lots of disks, i'm afraid thats not an economically feasible option.

What is possible is to use another workstation pc thats got enough processing power .. and use that as the 'processor' of the file server. Ie I want to have users connect to the workstation that has enough horse power, and attach the disks (through nfs perhaps) from the file server to the workstation.
and then have something like 'write cache' enabled on the workstation, so the users get fooled into thinking that there is fast file server they connect to.

I was thinking that if something can be tweaked thats probably slackware but i don't know if its possible and how to go about something like this...
any ideas?

Problem is: you have a file server; you're using it as an everything server. What you suggest sounds like transferring the cpu load of the atom based server to the network :-/.

A simpler approach might be to do a lot of small things, instead of one big thing. Farm all cpu intensive processes off to some new server. Disk access is hardly dragging an atom to it's knees. Remove the facility to open files on it directly. Relegate it to a file server. Over a weekend you could even relieve it of it's disk collection and transfer them to some other box.

what do you mean it's an everything server?

indeed disk access might not bring atom down, but disk access + 40*smbd plus a few other non constantly operating processes (http & ssh management, rsync server etc) are indeed maxing out the cpu usage.

I could use the fast workstation as the samba server and connect to the current file server through nfs shares but would I see significant improvement in the open/save speed over the network?

samba/cifs is a CPU hog. My e8500 hits 30% CPU with a single client doing transfers. The CPU usage is not linear though, 4 clients hit ~50% CPU, 8-12 clients hit 60% (never had more than 12 simultaneous transfers). I can understand the atom crawling IF 40 cifs clients all attempting to stream the same file at the same time. You could turn the the atom into a simple disk store, and have the workstation handle all authentication. But I think it's worth exploring the situation further.

You'd have to examine the network traffic and see where the bottleneck is. It might actually not be the atom, but the limitation of your networking equipment, the limitation of the disk system in the atom ... Hopefully with 40 clients you are using a caching raid card. If this atom is using a single drive -- of course you're experiencing lag ;)

well the network topology is as follows:

the office network is 100Mbit, all connected to 2x, 24port, 100Mbit switches. obviously, the 2 Mbit switches are connected to each other.
a small Gbit switch is connected to one 100Mbit switch, through a utp-5e cable. On the Gbit switch, I have connected both ethernet ports of this file server. I have also connected the old server.

This file server is a QNAP box with 6x 1TB disks in RAID-6, but i think its not hardware raid.
-I get a transfer rate of 13.5MB/sec* between the 2 servers. (all connections on gigabit - ok the bottleneck here are probably the disks)

I get 5.52MB/sec* between the new file server and a client pc (the bottleneck is probably the Mbit part of the network and/or the client disk (its a system with single SATA II disk).
I get 5.48MB/sec between the old file server and the same client pc transferring the same file.

So not much difference on single file transfer.
Yet, users at the office complain that file open/save operations are slower that with the old server. (a core 2 duo with RAID-1 disks). So it seems that its the concurrent connections that gives this apparent slow-down. Make me believe it is the atom after all.

How do you propose I go about it? nfs-export the folders from this file server to the fast carrying cpu workstation? or some other way?

That's bad. Really bad.
I get 70-90MiB/sec transfers with gigabit. 70-90MiB is the limitation of my disks.
100mbit network (in my experience) maxes out at 8MiB/sec. 5.52MiB/s isn't max speed, but understandable in a 100mbit network.

You could put the fastest server with 100x the speed disks in place, and you would still be limited by the network. I'd investigate upgrading to gigabit hardware across the board.

I've read/seen QNAP's benched at 50-120MiB/s (depending on drives and RAID level). The TS459PRO with 4 drives in RAID6 benches ~60MIB/s. Of course QNAP has different models available, and some are upgradable (RAM that is). IMO if you add another server to do authentication, you will only be adding yet another layer of slow down to the network. I'd investigate the settings of the QNAP, could be a configuration issue, and seriously contemplate getting some gigabit switches in place.

You might want to read this article - http://www.tomshardware.com/reviews/...lkit,2025.html

---edit---
The QNAP is designed for your application. You may even want to hit up their support forums.

it is really bad indeed.
I'm looking into acl's (which are enabled) and might slow it down, there is also a bunch of groups and users and folders with group access settings... but can these really bring the network to its knees?

as a crude estimate: dd if=/some 7G/iso file of=/dev/null gives 148MB/s... os it's not the reading from disks.
the 20MB/s was done over a 5-port gigabit switch. So it can't be the switch.. can it?

In the image it's visible that tranfer peaks at even 58MB/s but it had its silent periods too..