[SOLVED] Mounting /var & /tmp on HHD when using SSD!

satinet · 06-06-2016, 09:56 AM

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

satinet · 06-06-2016, 10:06 AM

ok sorry, I needed a comma between none and bind.
oh well I don't remember that being the syntax!

keefaz · 06-06-2016, 10:48 AM

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)

kjhambrick · 06-06-2016, 11:19 AM

Quote:

Originally Posted by keefaz

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)

Me too keefaz ...

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
/mnt/hdd/var /var ext4 none,bind 0 0
/mnt/hdd/tmp /tmp ext4 none,bind 0 0

Nice !

-- kjh

archfan · 06-06-2016, 11:29 AM

Why not simply link /tmp to /dev/shm?

That way you don't waste precious disk space for temporary files.

bassmadrigal · 06-06-2016, 12:38 PM

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:

Originally Posted by satinet

ok sorry, I needed a comma between none and bind.
oh well I don't remember that being the syntax!

You always need commas between your options. Look at your /dev/sda1 /dev/cdrom, and devpts entries for additional examples

GazL · 06-07-2016, 04:03 AM

Quote:

Originally Posted by kjhambrick

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
/mnt/hdd/var /var ext4 none,bind 0 0
/mnt/hdd/tmp /tmp ext4 none,bind 0 0

If you're going to do that, it should be:

Code:

UUID=9ae9133a-fbc8-4cc3-8bb2-3237b66b40fa /mnt/hdd ext4 defaults 1 2
/mnt/hdd/var /var none bind 0 0
/mnt/hdd/tmp /tmp none bind 0 0

'none' isn't an option, it's the fstype, and somewhat counter intuitively, 'bind' is an option even though one would logically expect it to be the mount type.

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.

satinet · 06-07-2016, 04:25 AM

Quote:

Originally Posted by GazL

If you're going to do that, it should be:

Code:

UUID=9ae9133a-fbc8-4cc3-8bb2-3237b66b40fa /mnt/hdd ext4 defaults 1 2
/mnt/hdd/var /var none bind 0 0
/mnt/hdd/tmp /tmp none bind 0 0

'none' isn't an option, it's the fstype, and somewhat counter intuitively, 'bind' is an option even though one would logically expect it to be the mount type.

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.

Thanks. That's very stupid of me. Makes sense now.

satinet · 06-07-2016, 04:27 AM

Quote:

Originally Posted by bassmadrigal

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.

You always need commas between your options. Look at your /dev/sda1 /dev/cdrom, and devpts entries for additional examples

Thanks for the advice. I have got the SSD working okay now. At the moment /tmp and /var are on the SSD. It wasn't great fun. My dvd drive is broken (resintall lilo!) and my computer boots the other drive you select for some reason (if you select drive a it boots drive b and vice versa??). Guess I shouldn't be running an amd athalon 64 any more......

Boot is now much faster at least.

bassmadrigal · 06-07-2016, 07:21 AM

Quote:

Originally Posted by satinet

Guess I shouldn't be running an amd athalon 64 any more......

I'm still running an 8+ year old AMD Athlon64 X2 (although, I'm seriously considering upgrading to the soon-to-be-released AMD Zen platform at the end of the year... it'll be quite the performance bump), so I feel your pain.

satinet · 06-07-2016, 07:46 AM

Quote:

Originally Posted by bassmadrigal

I'm still running an 8+ year old AMD Athlon64 X2 (although, I'm seriously considering upgrading to the soon-to-be-released AMD Zen platform at the end of the year... it'll be quite the performance bump), so I feel your pain.

I'm running KDE - the performance of the machine is actually fine (2gb ram). Now the SSD is working boot and application starup are better.