If you're using SSD as boot drive what's your setup? Moved your user directory?

[Luba]

If you're using SSD as boot drive what's your setup? Did you moved your user directory? Or maybe you just moved your Mail folders? Or perhaps you made no changes.

[BeyondMountains]

If you're using SSD as boot drive what's your setup? Did you moved your user directory? Or maybe you just moved your Mail folders? Or perhaps you made no changes.

i'm curious to see people set ups
was thinking about getting a 32gb ssd start up drive

[Boneoh]

Yes, I've moved the user files to the hard disk, a 3 disk RAID 0. I only have the OS and applications on the SSD. Performance is very nice, gotta love these SSDs.

[3587]

So is everyone just keeping their user directory on the old drive? Trash the system after moving it to the SSD? Will the applications look at the old 640GB HD then?

[Wild-Bill]

I haven't gotten any SSDs yet. I plan to buy two (probably 64's) and RAID-0 them.

Right now I've got a 74 gig Raptor as my boot drive. I moved my user folder to another drive. However, recently I developed a problem where I cannot log in to MobileMe. So My Mac Pro is not on MobileMe anymore. I think it has something to do with the relocation of my user folder. I don't know. I don't really feel like troubleshooting it anymore since I'll be putting the OS on some SSDs soon, and I may go for a fresh clean install.

THe way I moved my user folder was by going into System Preferences / Accounts, then clicked the unlock padlock. Selected my username, and (I think) option-clicked it to get the "Advanced" menu. Told it where I wanted the folder, and that was it. I don't know if that was correct though. Anyway, I didn't have any problems for the longest time, and then MobileMe stopped working with absolutely no way to fix it.

So I would say, if you are going to move your Users folder, do your homework first to ensure you do it correctly. :apple:

[bozz2006]

HERE is the correct method for moving your home folder. Wild-bill, seems to me like you did it right. you may want to check this against the method you used.

[Shazaam!]

One of the advantages of a SSD is a quick startup. Doesn't putting your user folder on a slower HDD defeat this objective?

[bozz2006]

the reasoning is that most of the user files will take up way too much space to fit on a SSD. and the startup volume isn't really bottle-necked by having the home folder on a SSD. for the most part, during startup, those files shouldn't even need to be accessed. moving the user folder speeds things up too. quicker access, since the drive doesn't have to search for user files and application files on the same drive at the same time. if I could fit all my stuff onto an SSD, that'd be awesome, but for now, having the boot volume on a SSD with the home folder on a separate HDD is the best option available.

[VirtualRain]

Everyone's strategy is likely to be different depending on how much storage they require for their home directory and how big their SSD(s) are.

In my case, my storage is allocated as follows:

OS/Apps: 40GB - system drive (dual X25-M's in RAID0)
Home Dir: 10GB - system drive
FCS Content: 100GB - media drive (1TB WD Black)
Video project archives: 100GB - media drive
Backup: 50GB - media drive (Ironically TC sucks for backups)
Download Archive: 50GB - Time Capsule drive (accessible from other computers)

I also have a Windows HTPC which functions as a BT client and NAS which has 3GB full of entertainment media.

[gugucom]

I have tried to put both OS X and Vista64 on a triple stripe 64 GB SSD. Before comitting to the purchase of a third SSD (I had two) I have experimented if I can really dual boot the array. I fell down at the point where Vista disk Management would not stripe multiple Bootcamp volumes. It was only prepared to stripe complete drives.

So I have now changed the plan and will buy a second set of 80 GB Intels. Those will become the OS X boot drives and the 64 GB drives will become the Vista boot drives.

I will keep EyeTv directories and iTunes on mass data drives. I do not use other programs that much because I primarily do web surfing and office from my uMBP. Download archives are on my TC.

[bozz2006]

can't wait til i can afford a couple of the new intel SSDs!

[pprior]

HERE is the correct method for moving your home folder. Wild-bill, seems to me like you did it right. you may want to check this against the method you used.

link no worky

[bozz2006]

Oops! Try this! (http://chris.pirillo.com/how-to-move-the-home-folder-in-os-x-and-why/)

[TheFuel]

Earlier this week I installed two 2nd gen Intel X25-M 160gig drives as RAID-0 in my '08 MP (3.2/16gig). My reason for RAID-0 was to bump up the read+write (mostly write) speed while maintaining the considerable access time advantage.

Settled on a 16kb stripe after testing against 128kb stripe. My test wasn't thorough, nor did it test for the settled upon layout. Various benchmarks prove inconclusive, best to test against your data set. That said the Internet consensus, based on Windows benchmarks, states 'the' optimal stripe size is 128kb - whatever. The drives are so fast comparatively that I'm not sure its worth the time to optimize more; my apps load instantly as is.

The new array supplements my old array, 2x 150gig Raptors RAID-0. I moved everything from the old array to the new; the layout was standard but with separate drives for iTunes Library+Staging area, and TM. Next I moved downloads to the same drive containing iTunes lib, and placed my working set data (Client+Personal Projects) back on the old array.

For comparison I ran a clean build of a largish client project. This involves +4gig content + ~30k source files (mixture of c/cpp/obj-c/plist/etc.).

Old array (2x Raptors): 177s
New array (2x X25-M): 114s
Final split setup build time: 122s

As you can see a considerable improvement. The split doesn't hurt as much as I thought it might, plus I'm not needlessly ware-leveling the SSDs. The biggest improvement is app launching, Spotlight, etc. Those are spectacularly fast.

Summary
System (SSD array)
OS
User Folder
additions in /usr/local
Data (Raptor array)
Client Projects
Personal Projects
Media
iTunes Library
Staging
Downloads
Timemachine
Timemachine
External
Archive Data

SSDs mounted in optical drive bay.

[cvelezv]

Summary
System (SSD array)
OS
User Folder
additions in /usr/local
Data (Raptor array)
Client Projects
Personal Projects
Media
iTunes Library
Staging
Downloads
Timemachine
Timemachine
External
Archive Data

SSDs mounted in optical drive bay.

Are you using the two connectors from the optical bay (meaning you don't have an optical unit connected) or how are you sharing a single SATA connection between the two SSDs?

[VirtualRain]

Settled on a 16kb stripe after testing against 128kb stripe. My test wasn't thorough, nor did it test for the settled upon layout. Various benchmarks prove inconclusive, best to test against your data set. That said the Internet consensus, based on Windows benchmarks, states 'the' optimal stripe size is 128kb - whatever. The drives are so fast comparatively that I'm not sure its worth the time to optimize more; my apps load instantly as is.



Hi, what was your reasoning on the 16K stripe size? It may be that your testing was on your fresh new drives where the write erase penalty was not yet a factor? What's your Xbench disk results?

Apparently, the consensus on a 128K stripe is founded on sound reasoning that the erase block size on Intel drives is 128K. That is, for any block that already contains data or once contained data, the drive has to first load the 128K block, add the new data, and then write it back. You can see why having a stripe size equal to an SSD's write erase block size is advantageous. Consider that with a 16K stripe, if you write 64K of data to your array in one operation, it will break down into two write operations on both drives... which means there's potential for 4 write erase block penalties and a total of 512K of data needs to be read and written. Alternatively, with a 128K stripe, only one drive is involved in the operation (so there is less paralellism) but you are only incurring a single write erase penalty.

It's rumored that other (non-Intel) drives have even larger erase blocks (up to 512K) which is why their random write performance so poor and these drives would be even worse in a RAID array.

Cheers.

[TheFuel]

Hi, what was your reasoning on the 16K stripe size? It may be that your testing was on your fresh new drives where the write erase penalty was not yet a factor? What's your Xbench disk results?


Reasoning was file size distribution in my working set (source code, scm, doco, UI artwork, frameworks, etc.). 40% fell into the 0-16kb range, an additional 20.9 fell into the 16kb-64kb range. As you can see >60% of my data is significantly smaller than 128kb. Next I looked beyond my data set into Apple's SDKs and frameworks. Here I found >80% of files fell in the 0-16kb range, climbing to >90% for 0-64kb. Finally I performed the same analysis on /Applications and found that >80% of the files fell into the 0-16kb range; expanding to 0-64kb and it climbs to >95%.

Then I tested build times, the build times cited above were based on the 16kb stripe. The 128kb build time was 153s.

I did use XBench too, but just an secondary benchmark. Of course I thought of the scenario you mention and ran 3 test { 16kb, 128kb, 16kb}, because I knew my working set I was fairly confident in my decision. It probably would have been wise to have done another 128kb run but I was happy with the performance I was getting.

XBench Scores

Test 1: 16kb
Results 426.96
System Info
Xbench Version 1.3
System Version 10.5.8 (9L30)
Physical RAM 16384 MB
Model MacPro3,1
Drive Type System
Disk Test 426.96
Sequential 276.44
Uncached Write 290.23 178.20 MB/sec [4K blocks]
Uncached Write 296.42 167.71 MB/sec [256K blocks]
Uncached Read 155.40 45.48 MB/sec [4K blocks]
Uncached Read 822.71 413.49 MB/sec [256K blocks]
Random 937.33
Uncached Write 1072.27 113.51 MB/sec [4K blocks]
Uncached Write 428.62 137.22 MB/sec [256K blocks]
Uncached Read 2391.72 16.95 MB/sec [4K blocks]
Uncached Read 1713.35 317.92 MB/sec [256K blocks]

Test 2: 128kb
Results 334.31
System Info
Xbench Version 1.3
System Version 10.5.8 (9L30)
Physical RAM 16384 MB
Model MacPro3,1
Drive Type System
Disk Test 334.31
Sequential 216.26
Uncached Write 188.51 115.74 MB/sec [4K blocks]
Uncached Write 223.39 126.39 MB/sec [256K blocks]
Uncached Read 151.64 44.38 MB/sec [4K blocks]
Uncached Read 471.52 236.98 MB/sec [256K blocks]
Random 736.22
Uncached Write 457.20 48.40 MB/sec [4K blocks]
Uncached Write 470.66 150.67 MB/sec [256K blocks]
Uncached Read 2532.52 17.95 MB/sec [4K blocks]
Uncached Read 1376.61 255.44 MB/sec [256K blocks]

Test 3: 16kb
Results 400.90
System Info
Xbench Version 1.3
System Version 10.5.8 (9L30)
Physical RAM 16384 MB
Model MacPro3,1
Drive Type System
Disk Test 400.90
Sequential 249.82
Uncached Write 247.50 151.96 MB/sec [4K blocks]
Uncached Write 240.04 135.81 MB/sec [256K blocks]
Uncached Read 153.64 44.96 MB/sec [4K blocks]
Uncached Read 771.36 387.68 MB/sec [256K blocks]
Random 1014.40
Uncached Write 1103.86 116.86 MB/sec [4K blocks]
Uncached Write 494.71 158.37 MB/sec [256K blocks]
Uncached Read 2244.58 15.91 MB/sec [4K blocks]
Uncached Read 1753.20 325.32 MB/sec [256K blocks]




Apparently, the consensus on a 128K stripe is founded on sound reasoning that the erase block size on Intel drives is 128K. That is, for any block that already contains data or once contained data, the drive has to first load the 128K block, add the new data, and then write it back. You can see why having a stripe size equal to an SSD's write erase block size is advantageous. Consider that with a 16K stripe, if you write 64K of data to your array in one operation, it will break down into two write operations on both drives... which means there's potential for 4 write erase block penalties and a total of 512K of data needs to be read and written. Alternatively, with a 128K stripe, only one drive is involved in the operation (so there is less paralellism) but you are only incurring a single write erase penalty.


Yes I'm fully aware of the reasoning here. I'm sure we've read all the same articles. I read several forum threads where you (or someone with the same nick) were involved in discussing this exact topic and over the course the the thread observed the light click on in the individual.

The problem with this reasoning is it doesn't account for the obscure path from high level API to device and presupposes a given benchmark is representative of the deployment environment.

A wise teacher once told me that if you want to become proficient at something then practice it. I think an analogy can be drawn here.

[TheFuel]

Are you using the two connectors from the optical bay (meaning you don't have an optical unit connected) or how are you sharing a single SATA connection between the two SSDs?

The '08 Mac Pro has a total of 6 SATA connectors. 4 are for the sleds, I'm using the two spare/unused SATA connectors. The optical drive uses a PATA interface.

[nightfly13]

FWIW, I just moved my iTunes and iPhoto libraries to another disk (and then told each respective app where to look) and then my boot drive fit easily on a single 80gb Intel - I have 20GB to spare to install apps without too much fear. I'm not saying this was smarter than moving the home directory, but it was quite easy and works great. I suppose the advantage of this way is I have SSD-speed access to my documents, which aren't all that big.

[gugucom]

The '08 Mac Pro has a total of 6 SATA connectors. 4 are for the sleds, I'm using the two spare/unused SATA connectors. The optical drive uses a PATA interface.

I'm down one because I use an LG BD-ROM/DVD-RW off the ODD-SATA1.
As soon as I have everything (incl. Vista) reconfigured for SSDs I will be throwing the original Superdrive out and run from the LG only. The empty second bay will then get my 2 Vista SSD RAID0 drives and one of the two OS X SSD in an Addonix rack. This will give me three 3,5" HDD sleds for data and backup.

[VirtualRain]

Yes I'm fully aware of the reasoning here. I'm sure we've read all the same articles. I read several forum threads where you (or someone with the same nick) were involved in discussing this exact topic and over the course the the thread observed the light click on in the individual.

The problem with this reasoning is it doesn't account for the obscure path from high level API to device and presupposes a given benchmark is representative of the deployment environment.

A wise teacher once told me that if you want to become proficient at something then practice it. I think an analogy can be drawn here.

Interesting results... and I guess we have crossed paths elsewhere. :)

Hard to argue with your build time results. I gather read operations are where you are are mostly constrained (and likely most users for that matter)? In which case, the write erase block penalty is less relevant and the added paralellism of a 16K stripe size really benefits you given the files sizes in your working set.

I guess I need to do some more testing and look at my workload more closely, however, I just don't have time to invest to gain a fraction of a second here or there which is why I just went with prevailing wisdom which seemed well founded. One of my problems in optimizing my storage is that I don't have any task largely constrained by storage performance with which to benchmark against... my biggest workload is video rendering which is processor and memory constrained.

How does one determine the distribution of their working file sets? Is there an easier way than combing through directories and looking at file size info?

[TheFuel]

Google JDiskReport. You'll probably want to download the Java version instead of the OSX. The OSX version is a PPC build, not universal, and therefore requires Rosetta to run on Intel Macs. Rosetta is not installed by default with Snow Leopard. Also I'd venture to guess the Java JIT does a better job than Rosetta - although I've not performed a comparison.

After you perform a scan, you'll want to select the "Size Distribution" tab and "Show Details Table". This will make sense once you begin using the app. BTW I don't recommend scanning "/" as the app seems to eventually go into a black hole never to return or report anything.

One more thing an argument can be crafted based upon % of total space used, e.g. fewer files but much larger file. The question arises which are more frequently access and what are the access patterns like. I imaging creating a tool using DTrace to pull real usage stats but I don't have the time to craft such a tool just to gain minor perceivable performance benefits.