FreeBSD 9 filesystem

C

chrcol

How stable is the new journaling filesystem? I set up a new MySQL server which was stable running on 8.2, the owner insisted on cutting edge so had to put on 9.0 and after migrating the database across we get crashing tables galore, it happened again after a database repair as well. The same database moved back to the 8.2 server is now stable again after another repair.

The RAM in the new server is ECC, although I will test it anyway. Disks are SAS RAID10. Six-core Intel processor with hyperthreading so lots of CPU threads. Mysql 5.1.

In addition when running [cmd=]/usr/local/etc/rc.d/mysql-server stop[/cmd] the server would not shutdown instead the second PID changed as if it restarted, when force killing the first PID it then would shutdown with the command.

This is the one that wouldn't go down with the rc.d command.

[cmd=]/bin/sh /usr/local/bin/mysqld_safe --defaults-extra-file=/home/mysql/my.cnf --user=mysql --datadir=/home/[/cmd]

The my.cnf and sysctl tunables were the same on both servers.
 
There was some BUG at the 9.0-RELEASE but it has been fixed in 9-STABLE. I assume that we are talking about UFS Soft Updates Journaling (SUJ)?
 
Yep SUJ and it is using RELEASE-p3.

So the next question is if I were to bump it to STABLE would I have the bugfix without redoing the filesystem or does it need a newfs? On another server I hit a bug in STABLE hence this one been RELEASE. Surely a filesystem bug is worth of a RELEASE patch?
 
I have seen in the past critical bugfixes been done as well. Especially since RELEASE is supposed to be more stable than STABLE.

So basically 9.0 is been left as is with the default filesystem causing corruption?
 
chrcol said:
I have seen in the past critical bugfixes been done as well.
Click to expand...
Only if there have been security issues.

Granted, filesystem corruption could be considered as such. Integrity is part of security in my opinion ;)
 
Found a couple of URL's on this.

One is amusing, the first one is this site where I took part in another thread suggest they made a patch available to 8.x users to get this feature tested. Instead of course it would seem 9.0 RELEASE is the effective beta test marked as stable to get testers in.

http://forums.freebsd.org/showthread.php?t=9202

I think there needs to be a rethink on release policy because filesystem corruption is about as nasty as it gets, it's worse than crashes. Yes, I should have put my foot down more and not used 9.0 but at the end of the day it is RELEASE.

I also found this. Which I think is what vermaden is referring to (thanks).

http://lists.freebsd.org/pipermail/freebsd-current/2012-May/033815.html

So they have been working on patches for months, yet no one thought to make a new ISO image which disables SUJ by default until the filesystem is stable.

I am csup'ing STABLE now but it's clear I need to just disable SUJ and use basic softupdates since this is a production server which I don't want involved in a SUJ beta test.

Good news is though at least it seems I have the cause of the corruption and this news is better than still having no idea.

:)
 
Have you tried disabling the journalling on the filesystem to see if the stability issues go away?

You probably don't want to be running journalling for a database filesystem anyway, considering the DBMS does its own journalling.
 
phoenix said:
You probably don't want to be running journalling for a database filesystem anyway, considering the DBMS does its own journalling.
Click to expand...

Well, at least it does not make sense to run journaling on the WALs, since they are append-only files (usually) so a crash problem is really difficult to happen. However, I agree that probably journaling for a database filesystem is too much, I would prefer a RAID configuration instead.
 
As far as I know the UFS soft updates journaling bug in 9.0-RELEASE affects only UFS snapshots, the ones you make with for example dump -L (which in turn calls mksnap_ffs(8) behind the scenes). Turning off the journaling enables you to make snapshots again.
 
phoenix said:
Have you tried disabling the journalling on the filesystem to see if the stability issues go away?

You probably don't want to be running journalling for a database filesystem anyway, considering the DBMS does its own journalling.
Click to expand...

That was the plan, however the migration is now on hold and it's possible we will change this to 8.2 now as well.

I do have another server on 9.0 which isn't using SUJ (as it was upgraded with an existing UFS) and that's ok with data consistency.

Incidently in 3-4 hours of use 3 meg of data was lost.
 
Ok the server is now on 8.3, and none of the previous reported issues are back with the same hardware so it does like a issue specifically with 9 and I am assuming its the filesystem changes at this point. I couldnt retest 9 without SUJ properly as was very time limited.
 
You must log in or register to reply here.
Back
Top