Mounting /var & /tmp on HHD when using SSD!
Hi
I've moved my system over to an SSD, however I want to have /var/ and /tmp on the old hard disk, which is not /dev/sdb. /dev/sdb5 is my home area. This mounts fine on the new system. /dev/sdb1 is to contain /var and /tmp. /dev/sda1 contains the root folder. This is my Fstab. It will not work at all. argh! /dev/sdb3 swap swap defaults 0 0 /dev/sda1 / ext4 defaults,noatime,discard,errors=remount-ro 0 2 /dev/sdb5 /home ext4 defaults 1 2 /dev/sdb6 /mnt/storage ext3 defaults 1 2 UUID=9ae9133a-fbc8-4cc3-8bb2-3237b66b40fa /mnt/hdd ext4 defaults 1 2 /mnt/hdd/var /var ext4 none bind 0 0 /mnt/hdd/tmp /tmp ext4 none bind 0 0 #/dev/cdrom /mnt/cdrom auto noauto,owner,ro 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 proc /proc proc defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0 The two lines in bold are the ones not working. I have mounted /dev/sdb1 on /mnt/hdd Thanks |
ok sorry, I needed a comma between none and bind.
oh well I don't remember that being the syntax! |
I didn't know you could mount a partition from a disk mount point
(and I have hard time to figure out how that works, say with different filesystems on the partitions for example) |
Quote:
I need to study-up on bind mounts and loop mounts ... I tripped over the loop mounts in liveslak and it gave me a scare to see all the 'odd' entries in my `df` output. The secret seems to be first mounting the UUID on /mnt/hdd and then remounting directories from the mounted UUID as /var/ and /tmp/ ( I replaced the space the mount options with a comma ) Code:
UUID=9ae9133a-fbc8-4cc3-8bb2-3237b66b40fa /mnt/hdd ext4 defaults 1 2 -- kjh |
Why not simply link /tmp to /dev/shm?
That way you don't waste precious disk space for temporary files. |
I imagine you want to move those folders to a regular harddrive due to the wear capacity of SSDs, but did you know that SSDs are a lot more resilient than they used to be? I've covered this a lot in the past, because I keep seeing people not utilizing their SSDs to their full potential due to the unneeded worry that they'll kill their drive quicker.
See my relevant posts here and here for super detailed information. Long story short, techreport did a test on several SSDs a few years back and the first drive failed at around 700TB (not GB, TB), which exceeded Intel's specification by 30x (700TB equates to writing 380GB to the drive, every day, for 5 YEARS!), two of the drives went over 2PB of writes. So, not using your SSD for /tmp (which is where most packages are built, which can benefit from increased I/O speeds) is unnecessarily limiting your speed when building packages (and all the other things that happen in /tmp). /var I can more understand, because it's mostly log file stored in there, but if you serve webpages using /var/www/htdocs, and they get high hits, again, an SSD can provide better I/O. Also, I know at least sbopkg will download all sources to /var/cache/sbopkg, so your extraction operations would occur faster on an SSD. Quote:
|
Quote:
Code:
UUID=9ae9133a-fbc8-4cc3-8bb2-3237b66b40fa /mnt/hdd ext4 defaults 1 2 Putting /tmp on a tmpfs is a option you may want to consider and is something I choose to do even though I don't have a SSD. I don't like the idea of re-using /dev/shm as suggested above. IMO it's tidier to give tmp its own tmpfs instance rather than reuse one intended for another purpose. |
Quote:
|
Quote:
Boot is now much faster at least. |
Quote:
|
Quote:
|
All times are GMT -5. The time now is 08:10 PM. |