Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was running out of space on /var so I moved my db dir to /usr and noticed a significate decrease in performance. In addition I noticed that performance is much slower as well under any Jailed systems, I'm assuming because they are also on /usr. It's all partitions on a single disk so it's not specific to any hd performance or anything. What are my solution options? Thanks!

Output of tunefs on /var

tunefs: POSIX.1e ACLs: (-a)                                disabled
tunefs: NFSv4 ACLs: (-N)                                   disabled
tunefs: MAC multilabel: (-l)                               disabled
tunefs: soft updates: (-n)                                 enabled
tunefs: gjournal: (-J)                                     disabled
tunefs: maximum blocks per file in a cylinder group: (-e)  2048
tunefs: average file size: (-f)                            16384
tunefs: average number of files in a directory: (-s)       64
tunefs: minimum percentage of free space: (-m)             8%
tunefs: optimization preference: (-o)                      time
tunefs: volume label: (-L)       

I think my main concern is performance on my jails, with the only option being linking each one's /var onto the main /var further exacerbating my space issue.


# Device        Mountpoint  FStype  Options     Dump    Pass#
/dev/ad4s1b     none        swap    sw      0   0
/dev/ad4s1a     /       ufs rw      1   1
/dev/ad4s1e     /tmp        ufs rw      2   2
/dev/ad4s1f     /usr        ufs rw      2   2
/dev/ad4s1d     /var        ufs rw      2   2
/dev/acd0       /cdrom      cd9660  ro,noauto   0   0  
share|improve this question
Please edit into the question the file system's parameters. You can figure what partitions are mounted with the df command; then run those through tunefs -p /dev/da0s1 (substitute your disk locations). – Chris S Mar 16 '12 at 20:08
Paste the contents of your /etc/fstab you could have some rogue settings diratime or atime (quota/acls or anything else) on the /usr partition that is making things slower – Ben Lessani - Sonassi Mar 16 '12 at 22:07
Okay, I've added that. – franklin stine Mar 17 '12 at 1:09
Softupdates is turned on for /var, is it also turned on for /usr? It makes a difference in performance. – Chris S Mar 17 '12 at 2:21
Yes, softupdates is enabled on usr – franklin stine Mar 17 '12 at 4:49
up vote 3 down vote accepted

How is your disk partitioned? If /var is closer to the centre of the platters than /usr, it will be quicker for the disk to perform seek operations under /var than under /usr; whether that alone is causing the performance loss, is debatable.

As for improving performance again, I'm not sure - is there anything else on /var you could move away to make room for your MySQL stuff to go back? Things like /var/db/pkg, /var/db/portsnap etc are good candidates here, since the tools that use them don't mind slow disk access times.

share|improve this answer
It is the default FreeBSD partition configuration. I've moved everything back onto /var but am getting closer to filling it up after clearing out as much as possible (log, etc). I think my main concern is performance on my jails, with the only option being linking each one's /var onto the main /var further exacerbating my space issue. – franklin stine Mar 16 '12 at 20:38
Looks like you've gone through file system config with Chris S already. If no differences show up there, then I wonder if either reinstalling with a rearranged partitioning scheme and/or adding a new disk (preferably on a different controller) might be possibilities? Both are a lot of work up front, but depending on your use case, may be worth the hit. – D_Bye Mar 17 '12 at 11:32
Thanks, This is on a production server w/ a decent load, so I think my best option for now is to just add another disk and configure my partitions differently during install in the future. – franklin stine Mar 21 '12 at 7:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.