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

Discussion in 'Mac Pro' started by Luba, Aug 3, 2009.

  1. Luba macrumors 6502a

    Luba

    Joined:
    Apr 22, 2009
    #1
    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.
     
  2. BeyondMountains macrumors 6502

    Joined:
    Jan 11, 2008
    #2
    i'm curious to see people set ups
    was thinking about getting a 32gb ssd start up drive
     
  3. Boneoh macrumors 6502

    Boneoh

    Joined:
    Feb 27, 2009
    Location:
    So. Cal.
    #3
    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.
     
  4. 3587 macrumors 6502a

    Joined:
    Mar 23, 2008
    #4
    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?
     
  5. Wild-Bill macrumors 68030

    Wild-Bill

    Joined:
    Jan 10, 2007
    Location:
    bleep
    #5
    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:
     
  6. bozz2006 macrumors 68030

    bozz2006

    Joined:
    Aug 24, 2007
    Location:
    Minnesota
    #6
    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.
     
  7. Shazaam! macrumors member

    Shazaam!

    Joined:
    Apr 12, 2009
    #7
    One of the advantages of a SSD is a quick startup. Doesn't putting your user folder on a slower HDD defeat this objective?
     
  8. bozz2006 macrumors 68030

    bozz2006

    Joined:
    Aug 24, 2007
    Location:
    Minnesota
    #8
    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.
     
  9. VirtualRain macrumors 603

    VirtualRain

    Joined:
    Aug 1, 2008
    Location:
    Vancouver, BC
    #9
    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.
     
  10. gugucom macrumors 68020

    gugucom

    Joined:
    May 21, 2009
    Location:
    Munich, Germany
    #10
    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.
     
  11. bozz2006 macrumors 68030

    bozz2006

    Joined:
    Aug 24, 2007
    Location:
    Minnesota
    #11
    can't wait til i can afford a couple of the new intel SSDs!
     
  12. pprior macrumors 65816

    Joined:
    Aug 1, 2007
    #12
    link no worky
     
  13. TheFuel macrumors newbie

    TheFuel

    Joined:
    Feb 8, 2008
    Location:
    Bothell, WA (USA)
    #14
    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.
     
  14. cvelezv macrumors newbie

    Joined:
    Apr 14, 2009
    #15
    SSDs in the Optical 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?
     
  15. VirtualRain macrumors 603

    VirtualRain

    Joined:
    Aug 1, 2008
    Location:
    Vancouver, BC
    #16
    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.
     
  16. TheFuel macrumors newbie

    TheFuel

    Joined:
    Feb 8, 2008
    Location:
    Bothell, WA (USA)
    #17
    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
    Code:
    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
    Code:
    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
    Code:
    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]
    

    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.
     
  17. TheFuel macrumors newbie

    TheFuel

    Joined:
    Feb 8, 2008
    Location:
    Bothell, WA (USA)
    #18
    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.
     
  18. nightfly13 macrumors 6502a

    nightfly13

    Joined:
    Jul 17, 2008
    Location:
    Ranchi, India
    #19
    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.
     
  19. gugucom macrumors 68020

    gugucom

    Joined:
    May 21, 2009
    Location:
    Munich, Germany
    #20
    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.
     
  20. VirtualRain macrumors 603

    VirtualRain

    Joined:
    Aug 1, 2008
    Location:
    Vancouver, BC
    #21
    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?
     
  21. TheFuel macrumors newbie

    TheFuel

    Joined:
    Feb 8, 2008
    Location:
    Bothell, WA (USA)
    #22
    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.
     

Share This Page