My current setup...

sda = 120gb SSD with windows 7
sdb = 60gb SSD with Slackware64-14
sdc = 250 sata drive I use for current/testing

To reduce the number of writes on my SSD I was thinking about moving my /tmp directory to the -current /tmp directory on sdc. What would be the best method for doing this, I figure it just to edit /etc/fstab but I'm not 100% sure.

Thanks.

Hi,

you could create a /tmp directory on the other drive (if there isn't one).

Then mount this drive for example to /mnt/tmp/

Afterwards move (mv) the files from your /tmp/ directory to /mnt/tmp/

Then unmount /mnt/tmp/

Edit /etc/fstab and make an entry for the /dev/sdc partition
Now execute "mount /tmp".

Markus

Ok I think I am with you, right now I have sbc1 mounted at /slackware in my /etc/fstab, sdc2 is a swap partiton.

/dev/sdc1 /slackware ext4 defaults 1 1

and I have a tmp directory located there at /slackware/tmp so what would the correct entry in /etc/fstab be to make /slackware/tmp my working /tmp directory?

mh, I think you should simply create a simlink, when you want to use /slackware as before.

You can only mount a partition but not a directory on a partition. This means you could use the whole /dev/sdc1 for /tmp or the whole /dev/sdc1 for /slackware.

You should probably consider to create another partition, for example /dev/sdc2 or even a bunch of logical partitions on /dev/sdc (which gives you more flexibility).

Markus

If I have sdc1 already mounted at at /slackware (or where ever) could I delete the /tmp directory and create a symbolic link to the /slackware/tmp directory like so..

chmod 1777 /slackware/tmp
rm -r /tmp
ln -s /slackware/tmp /tmp

I posted this right before I saw your post lol. Yeah The symlink thing did occur to me, but I think I agree with you, there is nothing important on the drive now, its just current and since 14 is stable I think I am just going to partition it for more flexibility like you said.

Thanks for your help.

Yes, this will work.

Markus

You CAN mount a directory, after first converting it into a mount point using the --bind option to mount the directory onto itself...
...and then using the --move option to move that mount point to your target:
In fact, if you specify a directory as your mount "device" in fstab (with the bind option), Linux apparently is able to figure things out.

1 members found this post helpful.

mount --bind /slackware/tmp /tmp

However, I'd prefer to put not only /tmp but also swap on SSD as SSDs are small and fast. They are perfect for that purpose.

quanx is correct. The --bind option now works on directories. Apparently the kernel devs have addressed this in recent kernels because it was not too far back that the bind/move trick was necessary.

1 members found this post helpful.

Thanks for the info, but I fail to see why you would want swap and /tmp on your SSD if you don't have to? Yes you want your main program directories on there for the speed, but what is going to get written to the /tmp directory that would benefit from the speed increase.

Temporary data, of course. For example one of my programs caches a lot of arrays in /tmp.

Same reason to put swap on SSD.

Yeah I understand I am just saying on my system I don't have any programs writing massive amounts of data the the /tmp directory and my swap hardly ever gets touched so putting /tmp on the SSD would only add unnecessary writes to the drive which as you know can over time degrade the performance. Granted with newer gen SSD's this isn't much of a concern since it can take millions of writes before you take a performance hit. On your system maybe you see a benefit but on mine it wouldn't make any speed improvement. I don't think firefox cache and slackbuilds are really going to benefit from an ssd over a mechanical drive .

Although it's a bit beyond my understanding why if no program writes then there should come many unnecessary writes, I'd wish you good luck and have a nice day!

Hi,

I did not think of the "bind" option. Maybe this would be a proper solution.

As of the partitioning, as far as I know there is still the problem that SSDs have a very fast reading access but too much write access is harmful for such devices.

Therefore it is a good Idea, to have directories with much write access on a traditional harddrive (SATA in this case) and the directories which have much more read- than write-access on an SSD.

If I had such an SSD-device, I would leave /boot, /etc and /usr (with all the libraries and executables) on the SSD, but /home, /tmp and /usr/local on the SATA-drive.

As I suggested above I would create an extended partition on the SATA-drive and create logical partitions for /home, /tmp and /usr/local.

BTW: I don't think that a computer with enough RAM would benefit from swapspace on an SSD since the swapspace is (normally) not used. And if the swapspace is often used (due to too less RAM) I would think that it isn't good for the SSD to have as much write-access.

Markus

Have you considered using tmpfs for /tmp instead? Anything that is too large to use /tmp can always use /var/tmp instead.

In your situation I'd be inclined to put /tmp on a tmpfs and /var/tmp on sdc