How about the commonly used scheme.
SSD -> /, /boot, /boot/efi
HDD -> /home (and possibly swap)

Any more than that and you are trying to go back to the management methods we were required to use when the HDD sizes were in the MB and tiny GB ranges. (My first home computer had a whopping big 10MB hdd (in the days of the 8086 and 80286)) In those days careful attention to partition sizes and file system capacities was critical. Today, with the large drives available and the improved reliability it is not so important to micromanage it.

Today's SSDs are robust enough that you do not need to worry about damage from the normal system actions such as /tmp and logs.

Why not simply use LVM = Logical Volume Management? (It's probably already installed on your system.)

When you do this, physical resources are grouped into "storage pools," and logical resources such as mount-points are assigned to those pools. All of the physical resources which support a pool do so in tandem, and anonymously. Your files might be located on any of the devices – or several at the same time – and you no longer have to care.

If a filesystem begins to run out of space, simply add more storage to the pool, then resize the filesystem upward to recognize the newly available space. (This can be done "on the fly.")

Furthermore, you can manipulate both the logical and the physical picture independently, without downtime. For instance, you could add the SDD, add it to a common storage pool also shared by the HDD, then instruct LVM to "migrate" some or all of the content to the SDD, which it will proceed to do over the next little while without(!) shutting down your computer. If a physical device "begins to make ominous clicking noises," you can retire it and then take it offline, also without shutdown.

Wow! That LVM sounds very convinience.. The reason why i don't use it because i don't know it yet. I will take time for me to study it to know what are the disadvantage of LVM..

Sounds fair.
May i know; since ssd can makes system fly.. and if /home is located outside of ssd, will that be bottle neck to the speed ? because config files and some builded programs might be located in /home .. That's why i was trying to micro manage /home folder..

May be a very slight delay in reading the config files, but since they are tiny when compared to the total of loading an app it makes no significant difference in times involved. The big HDD delay that speeds might indicate would be storing downloaded large files, but since the HDD write speed is much higher than most download speeds that makes no difference in performance.

I would wager that even with the most critical of testing you will see no perceivable slowdowns with /home on the HDD and the rest of your system on the SSD.

Installed binaries, whether from the distro repo or from manually compiled apps are installed in the system directories, thus they would be on the SSD regardless.

1 members found this post helpful.

Thanks i know how to do it now.

Closed