Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the 'Boot some MacBook Pros via an ExpressCard solid state drive' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Boot some MacBook Pros via an ExpressCard solid state drive
Authored by: rhoerbe on Dec 27, '09 02:55:05PM
The idea to make use of the little used expresscard slot by using a ssd seems compelling to me, but there are some questions open:
  • How are my workflows accelerated? Booting my MBP is rarely part of my workflow, but opening tab #77 in Safari and having to wait 30s and more is a real concern. In my case Safari and Parallels become quite IO-bound and could benefit from faster disk-I/O.
  • The selection of files should be smart. Most files in /Library and /Applications won't be accessed frequently, but some users's file, e.g. in ~/Library will be. Hence it might be sensible to identify certain high-I/O activity folders, move them to the SSD and symlink them. This should result in a smaller set of optimized files, therfore a cheaper and less battery-consuming SSD.
  • I like Superduper as a secondary backup to time machine. The optimization should not interfere with it.
  • The last question for me is maturity, as there were many posts about sluggish performance in some SSD-products under real-world load.
I tried to find out which files/folders are good candidates for an SSD-placement, and how this can be automated. The first idea was to draw from the OS X feature Hot File Clustering; However, it was not updated for weeks, and I insinuate anyway, that OS X is not smart enough to analyze my bottlenecks, and falls back to expedite the boot process. Then I did some analysis with fs_usage:
sudo fs_usage -w -f filesys > fs_usage1.log
The analysis gives some idea about disk-I/O, like that Safari does some 18000 I/Os to open the windows from the last session:
grep ' W ' /fs_usage1.log |grep Safari|wc -l
While some files that cause waits can be identified with a file ID, some I/Os are addressed by physical block numbers, that I did not manage to map to a file path using fsck.hfs -B or hfsdebug. So I had to postpone my attempt to write a script that would swap hot spot files to a separate filesystem. Hints how to overcome these difficulties are welcome.

[ Reply to This | # ]