- Should I keep one of that 4 example dirs in
/run is often a mountpoint for
tmpfs -it is not supposed to survive reboot. And by the way,
/run as such is not FHS, IIRC.
- Should I leave anything else on the HDD?
Depends on lots of things. What filesystem do you use? Some are more SSD friendly; e.g. Btrfs has some features (that is not a complete list, just a hint on what kind of things need to be considered) that alleviate the traditional SSD problem. There are also other things that might help, for example mounting with the
- What do I have to care about (e.g. re-install and update GRUB after outsourcing
Changing data storage layout that involves moving the kernel generally requires fiddling with the bootloader. Another thing will be correctly referring to the partitions. Since your partition layout is going to change, you're definitely going to need to update
- Can I outsource
- Should I outsource /boot?
/boot can be pretty much anywhere the bootloader will be able to find it. And the bootloader can be pretty much anywhere the firmware (BIOS/UEFI/whatever) can find it.
Is it a good idea? Depends. What do you expect from such a setup? One would say that if you don't update the kernel too often, it will save the drive a bit, but since we are talking SSD here, it doesn't really matter, because the blocks will be allocated randomly from the underlying physical flash memory. If you want to use UEFI (and potentially SecureBoot) you are going to need a separate partition (which is actually usually mounted somewhere under /boot/EFI IIRC).
More importantly though, I suggest you ponder what you are actually trying to achieve. While I understand the SSD's flash wear fears, what you are suggesting is actually quite unlikely to give you much better experience: your proposal is pretty much to put just the system on the SSD. However, (supposing the computer has reasonable amount of RAM), whatever you'll run will be cached, which means that you'll see pretty much only the difference between loading several megabytes from either SSD or HDD:
Let's say you decide to start Firefox. Its main library (
libxul.so) has (order of magnitude) 80MB. Defragmented HDD will give you this in under 2 seconds. SSD is going to flash it out in something like 0.2 second. That's a ten time speed up. However, the library still needs to be processed by the run-tome linker (
ld-linux.so). Only then the process is started and you wait for it to initialise itself and start interacting with you. Now, how often does one start browser these days, that a 1.8 second is crucial?
If you are afraid of losing data to the nature of SSD, back it up often (you should to do it anyway). Actually I thinks there may already be some solutions that would mirror the SSD content to HDD in the background (something like a hybrid HDD, but on OS level rather than the HDD firmware).