Four reasons why I won't even answer this question:
2. I'm not going to presume what HP includes a microSD card for. That's beyond the scope of this forum.
3. It's more than just "dumb storage area" for your OS. Either you understand the technology and know how to apply it properly or you don't.
Firstly; I work for HP.
Secondly; Anything I say is completely my own opinion.
The idea of using the microSD card for running an O/S, (any type of O/S), is bad for the very reasons cyberjock outlined above.
Yes - It is actually possible to run an O/S on the SD. However, you need to take into consideration the type of O/S and loading on the SD card.
The SD boot media is generally considered to be a provisioning method. That is: you put in the SD boot media, and install the O/S from there.
If you are going to do so. HP recommends to use HP SD boot media.
Taking into account the below snippet, you will have to modify FreeNAS a fair bit to address these write issues.
<snippet from the SD boot PDF> -
http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA4-9872ENW.pdf
SD boot considerations
Enterprise server environments differ on requirements, goals, and applications being run. For example, VMware®
environments, where the focus is on performance and reliability with a small deployment footprint, the 8-GB SD media kits
are recommended.
SD boot may not be advisable for some environments. OS drive space services both reads and writes, and write-centric
operations affect the endurance of an SD card. The following situations may not be suitable for SD boot or may require re-
configuring their operation:
I/O profile - Write-centric configurations such as locally hosted databases or virtual machines (VMs) are not recommended.
Such configurations are best served with dedicated high-end shared storage. Using an SD card to serve VMs or databases
housed on dedicated storage helps both to isolate mission critical storage as well as maximize return on investment (ROI)
on high end storage solutions without requiring repetitive OS images.
Swapping – Swapping to SD is certainly allowed, but it will actually diminish both SD endurance and system performance.
Swap commits to SD will be much slower than simply maintaining those pages in memory. Since most servers today are
configured with plenty of memory to operate without a swap file, swapping can be turned off.
Logging - Although many people take system log files as a given, the continual commit of low bandwidth logs can slow
down SD-based systems and reduce SD endurance. SD counters in iLO can be used to measure and determine the amount
of writes idle logs can generate. You can improve logging performance by:
• Reduce logs down to the lowest amount possible.
• Re-direct logging for many systems to network attached storage instead of locally attached disks. This also provides
centralized locations for logs for collection of data.
Crash dumps - Although crash dumps are rare, default crash dump configurations are generally over cautious and in some
cases can be disabled. Reducing the size of crash dumps can allow a good middle ground while still providing some of the
features and desired event analysis.
Hibernation files – In typical server environments hibernation features are used rarely—if at all. These features can be
removed without concern. In many cases, this will reduce hibernation file creation, which can slow startup, shutdown or
deployment events.