Solved [SOLVED] Moving /var to rotating media from my SSD

dcbdbis

dcbdbis

Unlike my last post, this one truly belongs here....

I am moving FreeBSD from off a new, but secondary drive where I have done most of my "learning curve" in FreeBSD from Linux.

In the new installation, I do not want the /var tree on the SSD.

In Linux this is what I did:

a) Booted to live media. Mounted the SSD and the rotating slice that is the target of the /var tree.

b) After moving the var tree I then updated the fstab on the SSD.

Reboot was uneventful and /var was on rotating media, helping me extend the SSD's lifespan.

It looks like the same procedure can be done here.

I am requesting a more experienced FreeBSD user to validate that my procedure is correct and will also work for FreeBSD.


Sincerely and respectfully,

Dave
 
Re: Moving /var to rotating media from my SSD

It can be done. dump(8) and restore(8) can be used to copy the filesystem correctly if it is already a separate partition. Otherwise, I'd probably use rsync(1) with a long list of options to handle links.

Remember that FreeBSD does not put application data in /var, so it is not subject to very many writes. On FreeBSD, that data (MySQL databases, for example) would go in /usr somewhere.
 
Re: Moving /var to rotating media from my SSD

The procedure you use for Linux is the same for FreeBSD.

The gold standard to recursively duplicate the contents of a directory is, as root, rsync -HAXax source-dir/ dest-dir/. I always read the manual closely if I want to vary from that. [cpio(1), tar(1), and dump(8)/restore(8) can all achieve similar results, with some caveats, but rsync(1) is now universal.]

I have a laptop Running MS Win 8, and Oracle VirtualBox, with a FreeBSD 9.1 virtual machine. The laptop has no moving parts, and I mount /var/log and /tmp on tmpfs(5) file systems. The logs don't achieve any longevity, but the main aim is to move the volatile parts of the file system to to memory, and thus discourage unnecessary wear on the SSD.

Cheers,

--
Phil
 
Re: Moving /var to rotating media from my SSD

wblock@ said:
On FreeBSD, that data (MySQL databases, for example) would go in /usr somewhere.
Click to expand...
By default MySQL stores it's databases in /var/db/mysql/.
 
Re: Moving /var to rotating media from my SSD

SirDice said:
wblock@ said:
On FreeBSD, that data (MySQL databases, for example) would go in /usr somewhere.
Click to expand...
By default MySQL stores it's databases in /var/db/mysql/.
Click to expand...

Yes, but that's a relic from other systems, and should be overridden on FreeBSD because our traditional separation between the base system and add-on applications is really a good thing. (I meant to add another sentence to that earlier post, but got distracted and wandered off before doing so.)
 
In other PM's and emails, wblock has assured me that there isn't a lot of activity in the /var tree. So I left it on the SSD.

For others looking to deploy an ssd, I would recommend this excellent article by wblock on SSD usage: http://www.wonkity.com/~wblock/docs/html/ssd.html.

Make sure you follow it exactly when you issue a newfs -U -t call to enable trim support. The -t parameter is what releases the trim magic. I wanted a validation that it worked, so I rebooted to single user mode and then issued a: tunefs -t enable <YourDiskSlice>. When I did this, tunefs promptly complained that this flag was already set.......and then I smiled after receiving validation. :)

I have been monitoring the date/time stamps of the /var tree. And it is just like wblock stated....There is little write activity in this tree. There is more write activity generated by my mail client than there is in /var.


My thanks to all who took the time to respond. It was all helpful.


Sincerely and respectfully,


Dave

Edits: Spelling, Grammar, and tag Corrections
 
You must log in or register to reply here.
Back
Top