May 8, 2010 I pass my Linux+ on-line course and I jump ship for FreeBSD the first chance I got. I been searching google for an answer for many months off and on, and today, all day and night all because I decided to give FreeBSD another try at dd'ng. I finally found a few threads with the same possible problem.

I notice while searching, many times there is a solution but no comparison which would makes the solution only a work around and truth is never gain in some cases. Here's an example and out of all of the hints I typed in google search box I only came up with these two thread from the entire world of BSD.

daemonforums.org/showthread.php?t=2077

and another one else where ...

Below should give you a general idea of the problem. I retested with clean partitions, reformatted exactly the same, complete shutdown and re-boot so there would be no side effects... I even done complete reinstall of all 21 partitions and 4 OS's many times and all FreeBSD's is always slow and get slower for no reason at all when you reverse steps, no matter what you do or how you do it. I use to say to myself, "LINUX is skipping something and FreeBSD is taking its time to do things right", but I never had a problem out any of my Arch-Linux dd style backups so today I concluded it's foolish of me to keep making excuses for FreeBSD. I'm at the point I don't beleive what I been seeing and I need some real life answers from experienced people.

Could someone please tell me what's going one here and how could this possibly affect a production system. It got to be something even if dd is not used directly, because if other functions use some of what dd (same line of code or two) does for other things in the systems and if so, there got to be some kind of unnoticeable effect. FreeBSD seems to be chewing on the wrong bits and pieces.

As you see above, "CLONE A PARTITION" Arch-Linux has always did a good job and it is consistence 95% of the time no matter how many back to back repeats I do, 5 min for 10GB and 21 min for 40GB is the working average I always get.

But at this moment while writing this thread, cloning with FreeBSD has taken over three hour. Here are the final results and I am burn-out. The average is usually only ½ hour or a hour and 5 minutes even for FreeBSD, depending on how freebsd feel at the moment, I guest

20980827+0 record in
20980827+0 record out
10742183424 bytes transferred in 12376.074103 secs (867980 bytes/sec)

That's 3 hours and 26 min and it strange that record in and out are even??? That not the correct way I been getting. Should be (last three digits) 827-826 or vice-versa. Things change so much I can't remember anymore. I was suppose to be learning pf and ALTQ options today but you seen what I get ... 3-hours per 10GB

As you may have figure, I am a real noob but my plan is, when I make a major changes, I may save one optimized for pf and another as a databbase and so on so. I rather dd to make a backup of the entire partition so there will be no possible flaws and moving from one machine to another is more easy for me to keep up with. Sorry for the long thread but I did'nt want to leave out any important detail.

I retried to be sure once again and it's official. This is a problem and not my imagination. I use difference downloads of FreeBSD running on virtually new modern hardware. So, just minutes ago, I just retried everything using Arch-Linux and these are some decent numbers for operation on two 10GB partitions of the exact same size:

Also, I understand that record in and record out are always the same size when you (dd) copy and restore.

In the end I will be dumping to do backups just like most other people but I think it's weak when you notice something wrong with one (known be perfect)standard but move on to something else that works, leaving behind a problem that may come back to bite an entire project or all of your work in the end just because no one paid attention or even knew it existed. If the creators of FreeBSD don't know already, maybe someone of experience will test and send in a bug-report so we can get some answers. I really like Arch-Linux, but not as a work-around for FreeBSD unless there is no hope.

I don't know if it's the case with FreeBSD, but on OpenBSD, using the raw character device node instead of the block device is better, as it bypasses the kernel buffer cache, and this can even improve speeds (..using a larger block size as stated by Carpetsmoker).

I don't know if it's the case with FreeBSD, but on OpenBSD, using the raw character device node instead of the block device is better, as it bypasses the kernel buffer cache, and this can even improve speeds (..using a larger block size as stated by Carpetsmoker).

What is your experience with softupdates? Is it going to improve or negatively affect the speed?

Thank you very much Carpetsmoker. I'm happy to have join your forum and I hope I will become as helpful for others as I see most of you guys are everyday. I got so much to learn before I can be sure of anything. After 16 week of being crammed with Fedora, you really don't remember things. Too much at one time, week after week, you want to try what you study (like Tripwire), but now, you got to do a 10,000000 word report about standards.

softupdates? Thanks Oko. The second thing that came up was Tuning Disks on a google search. It's now included for deeper review.

BSDfan666, could you please show me a few examples of what raw character device code looks like. I like the idea of bypassing the kernel buffer cache. Now I got a reason to recheck my Linux+ textbook, I remember reading about character and block device. School is especially good for terminology. I can build anything but never know the name of most items that I'm using. I hope to completely pin-point my problem by morning and post the results because I still see no excuse for this right now. Raw code with no flags should work nearly same for both OS I used. For now I think it's my set-up. It could be flaky by having 3-bsd's working on one another for one another and somehow detected it and got confuse. Completly dead files on another partition brought back to life somehow. I'll know by morning.

I don't know if it's the case with FreeBSD, but on OpenBSD, using the raw character device node instead of the block device is better, as it bypasses the kernel buffer cache, and this can even improve speeds (..using a larger block size as stated by Carpetsmoker).

@OP: You'll want to play around with the bs= setting, to find the value that works best for your disk setup. Generally, bs=1M works nicelyl. On some SSDs and fast disks, bs=16M is better. On other SSDs and disks, bs=128K or bs=512K works better. Only by testing your setup can you determine the best bs= to use.

All the time I wasted, it's going to be a thrill speed testing. I always wanted to try difference setting but was not sure what to start with, plus the danger of trying when my disk was loaded. The only thing I can hurt now is the MBR. No real work is on the disk. Perfect for testing what Carpetsmoker laid-out, and Thank you phoenix for making everything all so clear. Now I got something real to work with instead of pointing fingers at the OS.

The missing keyword everywhere I been: "You must give dd under FreeBSD a value unless you have plenty of time to spare"

Thanks again DaemonForums, I would have not tried this for another 6 month.

PS:
But one thing to beware of. If you are copying a FreeBSD version of a difference kind (i386 / AMD-64) to your extended DOS partitions and you try to copy it back some day like I just did using FreeBSD-i386 (on Par-1)... don't do it ... USE Arch-Linux, because when I just did it with FreeBSD it stripped or included the GEOM DOS label and FreeBSD on Par-2 did not work.

I did the exact same thing with Arch-Linux after re-booting and it worked. It all depends on what you're trying and this does prove that these OS use the dd program differently which in my case Arch-Linux does fine. FreeBSD need more code to fix the disk in this situation. So this way is easy and safer for what I just seen.
...............................
...............................