I know I'm being a Johnny-come-lately to this question but I'd like to see if I can shed some light on this for anyone searching.
First, @ppetraki's answer is excellent.
The short answer to "Can I RAID SSDs and boot from them" is "Yes!". Here are instructions for 14.04. Instructions for RAID configuration on 12.04.x are identical, but this tutorial using 9.10 has pictures. Following here are some important gotchas and details I had to discover the hard way, through personal experience:
I'm running Ubuntu 12.04.5 with the 3.8 kernel on an MD RAID0 configuration and the SSD-friendly Btrfs filesystem. I run fstrim as a weekly cron.
My extra Btrfs mount options from fstab:
defaults,ssd,ssd_spread,space_cache,compress=no,noatime
The 3.8 kernel is required if you want to use compress=no
as a Btrfs mount option and may also be required for use of fstrim
, the manual trim command used for scheduled trim.
You must also manually align partitions (on any multi-partition setup, raid or not) on the SSDs BEFORE booting to the installer because depending on the page size of your SSD, only the first partition will be properly aligned (it took me a while to catch it) and this can severely impact drive lifespan. You can do this from a command prompt within the installer or from a live usb/disc before you attempt installation. Caveat: Do the math yourself. Fdisk will lie about alignment.
Further reading: I think Btrfs can even create its own raid arrays.
Regarding TRIM:
It's arguably unnecessary thanks to overprovisioning
14.04 is the first release to enable TRIM support out-of-the-box but it's trivial to enable on previous distributions, provided you are using kernel 2.6.33+.
Depending on your chosen filesystem, you can enable trim/discard by editing your fstab and setting the appropriate mount option. The difference between doing this and running it via cron is that the first will trim/discard on-the-fly and the second will do it in a lump on a schedule. I use the second.
Does it matter? Supposedly, the online discard (using the mount option) is not wonderfully implemented and is slow so it's "not recommended". I can tell you that my "hdd" (hehe) lights go nuts for 10-20 minutes when the weekly cron job runs but the OS responsiveness is almost completely unaffected.
Booting from the array
Though I don't see this in a quick scan of the ubuntu 14.04 instructions, I had to create an additional primary partition that is NOT part of my raid arrays. Disk 0 has a 500mb primary partition of ext3fs. During installation I told the installer this was to be mounted at "/boot" and I set the bootable flag. The bootloader is then installed here so the OS can start and then mount the RAID. The remaining Disk 0 space is divided between 2 partitions which are later used for the MD arrays that become "/" and "/swap". Disk 1 has the same, but no boot partition. Also, I only created the swap in case I need it sometime and btrfs does not support swapfiles. This partition is never mounted; after installation, I commented it out in my fstab.
Forgive all the edits, just trying to get it all out there.
Honestly, I'm not buying into either premise.
First, I'm not sure what is meant by regularly but I can't imagine wiping an SSD often enough to wear it out. I have several systems with SSD drives that I use daily and some of them I have wiped occasionally.
Second I see no problem with using dd
or dc3dd
to wipe an SSD. If there is concern over the wear levelling algorithm leaving data behind in "spare" sectors, several runs should do the trick. How many runs are "secure" will certainly be a matter of opinion.
Recommended:
dc3dd wipe=/dev/sdX
where sdX is the drive (ex. sda, sdb, sdc,). You can also specify pattern=HEX (write HEXadecimal value to every byte of the output)
textpattern=TEXT (write the string TEXT repeatedly to the output)
Alternately:
You can blast a drive full of zeros (fast) or random or semi-random data (more secure)with dd as follows:
sudo dd if=/dev/zero of=/dev/sdX
where sdX is the drive (ex. sda, sdb, sdc,) changing /dev/zero to /dev/random or /dev/urandom will change to filling the with random data instead of zeros
Note: I read some test results that indicate that The dc3dd tool can be used for a variety of forensic tasks (e.g., disk imaging or wiping
media for reuse).
In all the test cases run against dc3dd version 7.0.0, all visible sectors were successfully
overwritten. Sectors hidden by an HPA (FMP-03-HPA and FMP-03-DCO-HPA) were
also overwritten; however, sectors hidden by a DCO were not removed (FMP-03-DCO
and FMP-03-DCO-HPA). By design, the tool does not remove either Host Protected
Areas (HPAs) or DCOs. However, the Linux test environment used (Ubuntu 10.04 LTS) automatically
removed the HPA on test drives, allowing sectors hidden by an HPA to be overwritten by the tool.
Test case source: conducted for the U.S. National Institute of Justice by the Office of Law Enforcement Standards of the National Institute of Standards and Technology.
The version I use is 7.1.164
Best Answer
Currently there's no way to securely erase files on SSD without erasing the content of the whole drive or access to the firmware of the SSD.
It's impossible to know where the SSD may store previous copies of a logical block.
To make matters worse, due to journalling and copy-on-write mechanisms of the file system it may be impossible to know which logical blocks may hold a previous copy of a particular file.
The only way to prevent the leakage of deleted files to someone with direct access to the drive is to encrypt them in the first place and keep the encryption key safe from prying eyes.
Addendum:
I did some research and found out that you can sort-of erase all previously deleted files if you manage to learn all the unoccupied sectors of a file system, which is generally possible and offered by some file system tools (e. g. for the ext* family), and then discard them (e. g. with
blkdiscard(8)
as outlined in this answer to the linked question), which returns the blocks for garbage collection until they're used again and overwritten in the process.This is secure against everyone who cannot access the flash cells directly, so everyone who