sysinstall has been deprecated in FreeBSD 9. The new, and better way, to install FreeBSD is using the bsdinstall software.
If you want to use a Linux Server I would recommend you to create a custom mfsBSD image with FreeBSD 10.0-RELEASE as the basis. In this image you can create a custom rc.local file to automatically start bsdinstall and even make an unattended, or partially unattended, installation with a answer file in /etc/installerconfig
If you look in the bsdinstall(8) manual there are infos about the unattended install.
To boot the image from the Linux server you should use memdisk with arguments, like this:
#FreeBSD 10.0 RELEASE amd64
label 1
menu label ^1. FreeBSD 10.0 AMD64
kernel memdisk
append initrd=freebsd/mfsbsd-10.0-RELEASE-amd64.img harddisk raw
#FreeBSD 10.0 RELEASE x86
label 2
menu label ^2. FreeBSD 10.0 i386
kernel memdisk
append initrd=freebsd/mfsbsd-10.0-RELEASE-i386.img harddisk raw
You shouldn't create ISOs to network booting, just BUILD plain image files with mfsbsd-2.1. Get it here: http://mfsbsd.vx.sk
Did you try to restart the machine? Did it any difference?
If a restart did not help, what you are facing can be a problem with excessive fragmentation, which is #1 enemy for rotating media (read: HDDs). The high number of snapshot can exacerbate this situation.
To confirm the issue, try the following:
- create a new similarly sized file with the command
fallocate testfile.raw -l <size>
- try to read the newly-allocated files. If it read fast, then fragmentation of the old file is probably the culprit.
If you confirm that this is a frag issue, follow these steps:
- stop MySQL
- take a backup of your table.ibd file
- rename it to table.ibd.old (
mv table.ibd table.ibd.old
)
- copy it to the previous file name (
cp -a table.ibd.old table.ibd
)
- restart MySQL
EDIT after iostat update
Thank you for the iostat number.
You moved to the ZFS array a 15 GB file in about 67s, this means an ingestion rate of 223 MB/s or 55 MB/s per disk (excluding the mirrored ones). On the other hand, your iostat seems to report about that (about 25 MB/s), so I attribute that discrepancy to a compression ration of about 2:1.
OK, this is good. However, during read strange things happen...
Discarding the cat
result (cat
use a very small buffer by default, and with disabled prefetcher it surely is way slower then cp
), the cp
command is way to slow: you copied a 15 GB file in about 1530s, which mean an extraction rate of only 10 MB/s. And that is already factoring the compression advantage. On the other hand, your iostat number shows over 5 MB/s reads per disks, which add up to about 40 MB/s per array. Factoring the 2:1 compression ratio, it should give you a transfer rate north of 80 MB/s. This means that you are at about 1/8 your read potential.
The question is: why? It really seems as the CPU was maxed out during the transfer. Can you run a top
and a dstat
session during reading the affected file? If possible, configure top
so show the per-CPU load.
Best Answer
You need to replace /bin/sh with something; that's the key. If you can get into the FreeBSD loader during startup (with an "ok" prompt) try something like this:
I got this information from loader(8) from the FreeBSD manual pages (online). I've not done this, but it should work (assuming that /bin/csh is present and executable).
If you have a FreeBSD 8.2 server up and running elsewhere, you could try stealing the /bin/sh from that source and putting that into the system where needed.
Alternately, get a statically built /bin/sh and put that in instead; there won't be any library problems with a statically-built binary.
EDIT: I should have noted: if you boot into /bin/csh, you still have to get something to use instead of /bin/sh. You can get it over the Internet or copy it from another CD or a package or something; using /bin/csh to boot gets you into the machine. Copying over the network requires that you bring up the network; otherwise, copy from a CDROM.
The best ways to avoid this in the future:
Do all three.