tyggna

[Log in to get rid of this advertisement]

I had an idea, and I want to bounce this off of the Linux community at large.

I've done a lot of work with NFS, and I find the best way to improve NFS is to give it more cache to work with on the server. As expected, Linux only caches data off the hard drive until it has filled available ram.

Normally, it seems absurd to use the swap file to cache things off the hard drive, but that is what I want to do.

My idea was to use a SSD Raid array as my swap partition and keep the bulk of user data on platters. That, unfortunately, won't help to speed up NFS response times, because it'll only expand the cache to fill available ram proper.

So my question is, where would I start looking to have Linux see my SSD as ram? Any ideas?

I'm hoping for a cool hackish solution using Linux tools and the /dev or /proc directories, but I'm not opposed to digging in and altering kernel code if needs be.

MS3FGX

So in other words, you want the kernel to address a physical device as if it where RAM, not just as a swap device?

tyggna

Exactly, any ideas?

jschiwal

You are describing something similar to a layered filesystem such as unionfs, but you have it backwards. That last thing you want to do is use an ssd for swap. The ssd drive has a limited number of writes. Reads may be faster but writes aren't. The main advantage of ssd over hard drives is if you have your hard drives spin down when inactive.

A better idea would be to layer a hard drive's partition over an ssd if you have a read-mainly partition. That would enable quicker reads but use platters for writes.

tyggna

I get what you're saying, but I'm not particularly concerned about the health or life of the SSD drive. If it's trashed in a year or two, I won't cry. My main concern is speed--just delivering the data off the hard drive to the client. The caching system is adequate to do this, but it's hard to stick all the ram required to handle several hundred NFS clients.

That's kinda why I'm looking for this hackish solution, because it'll spare us the financial pain of going with 15k rpm SCSI drives.

Also, we're looking at holding several dozen terrabytes of data storage on this machine, so it really isn't practical to put that amount of data on a SSD.

If we hosted programs over NFS, then I'd use that setup in a heartbeat.

jschiwal

An ssd drive will have worse write performance unless the system caches writes in ram. There are battery backed-up ram cache cards for raid-5 arrays.

onebuck

Hi,
Where are you getting the information on 'SSD'?

'SSD' are faster read/write than a hdd. Non-destructive R/W for a 'SSD', most have battery backup. If the 'SSD' had a limited number of writes then your RAM will have the same. I think your confusing the situation with a 'Flash'. 'SSD' is not a 'Flash' which does have limited writes. The big problem with 'SSD' is the limited size available but the density will be changing in the near future.

The speed advantage with 'SSD' is that no mechanical latency or propagation due to the rotating platter or the head seek that must be performed by a hdd subsystem. We've been using 'SSD' as ramdisk for years, the size of the memory was the restricting limitation not the R/W to the device. Why do you think that most distro use a initrd? Speed!

rweaver

Even better... http://techreport.com/articles.x/16255

onebuck

Hi,

Thanks for the link! Good review for the 'Acard'.

jailbait

You have three different storage speeds, in descending order RAM, SSD, and disk. If you set up SSD as being RAM then the RAM access speed will drop significantly and the CPU will appear to run much slower. Years ago I watched a company trying to utilize a combination of fast RAM, slow RAM, and disk. They told the operating system that fast RAM and slow RAM were all the same and no matter what they did they got a slower running system than if they just left slow RAM out completely. The technology of the day was not such that they could try using the slow RAM as a fast disk.

If you set up SSD as being disk then the disk access speed will increase, perhaps significantly. You would try to arrange the file system so that the most active part of the file system (journal?) is on the fastest device (SSD).

With NFS the slowest part of the system is almost always the network. So I suggest that you set up the NFS by including SSD as part of the NFS. Then set up the NFS so that the most active part of the NFS is on the SSD.

Your next question is of course, How? I don't know. But I think jschiwal is on the right track when he suggests:

----------------------
Steve Stites

onebuck

Hi,

'SSD' are independent of the system DRAM. The 'SSD' is a subsystem that is treated independent. The nice thing about a 'SSD' is that the local memory controller takes care of the timing for the 'SSD DRAM' therefore it will be transparent to the system overhead. If you setup a portion of the system DRAM to be a ramdisk then you certainly would have more overhead. The gains of a modern 'SSD' would surpass the old style of ramdisks. One the speed for the access of the 'SSD' would be greater. Second the way the 'SSD' is interfaced to the system will ideally surpass any older style ramdisk. Our current memory technology will be efficient except for the density of the 'SSD' but that will be changing in the next generation of memory and controller.

Most 'SSD' are designated as a drive on the system that it is installed in. Most are SATA but there are units that utilize EIDE.

As for how the 'SSD' utilization I would probably setup so the system activity for hdd would be maximized with the 'SSD'. Setup could be done at boot so the 'SSD' partitions are mounted to the proper mount points.

As for the transfer for 'SSD' it can be around 300MB/s, some manufactures claim speeds of at least 400MB/s. Of course the interface type would be SATA to get those speeds.

To use the 'SSD' for NFS would be one way but I wouldn't commit the whole drive. Your partition scheme would be important with a 'SSD' so as to provide a proficient drive.