first of all: great set of tools and thanks to all developers and contibutors.
I'm currently working with dd.exe from the coreutil package to write to large
files on Windows 2003 Server.
Problem is file write throughput degrades massivly after some time from about
40 megabyte per second to around 4 megabyte per second (steady decay over
aprox. 24h).
This is bad since i deal with a disk image with a size of 1 terrabyte.
On google i found much about syncronous file writes beeing the root cause for
such throughput degradations.
So i was pleased to find the nonblock-flag with dd.exe.
But my tests show there is no difference when using oflag=nonblock, not in
file creation patterns (as shown by Process Monitor) nor in throughput.
Even when looking at the source code (dd.c) I found no substancial
implications using or omitting oflag=nonblock.
Any thoughts on this topic?
I just want to transfer my 1 TB big disk image from a linux box to my windows
box to try out some propriatary XFS undelete tools but it's taking me days to
figure that out. Connecting the hard drives to my win. box is no option since
it's a md-tools raid.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You have an image file of your linux drive on your windows box? If I was doing
testing like that I would boot the image in a virtual machine. I like vmware
workstation because I can take snapshots and if I choose regress to a
snapshot. Snapshots become useless if you try to increase the size of the
virtual disk though, and they take up a lot of space.
re degradation over time, I have experienced that (not specific to dd or
gnuwin) but never by so much. I can't attribute the cause to any particular
thing. I'm interested in what solution you find to that problem. You could try
another version of dd, available here:
The usage is slightly different, and depending on the version it reports
different statistics.
Note that in the 0.6 betas:
--progress output is in the same unit as bs is specified with
As opposed to the way it is 0.5, reporting in bytes.
A note of caution (for anyone) that you could totally decimate your hard
drive if you don't know what you're doing with dd, or setting block size, or
if you don't understand the way windows object links and drive letters can
change. for example windows assigns volume4 and drive letter C to my main
windows partition when I boot with my raid plugged in, but when I boot without
the raid plugged in it assigns volume2 and drive letter C.
]GUID[
link to \?\Device\HarddiskVolume2
fixed media
Mounted on \.\c:
So you'd want to use a combination of winobj,, disk management console, dd
--list, etc so you can confirm what you're writing to. It's a mistake to
assume, oh, well, I always image to volume 5 or whatever so I'll just do that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Even if you create an image with no compression at all (to save time) it will
break it up into pieces of less than 2GB each. You want to create a Clonezilla
Live CD. Warning: if you decide to select LZMA compression the job may run all
day or longer.
Then of course when you copy the drive image to Windows Server 2003 you will
have to restore the image again using Clonezilla.
Note: the program can be configured to use DD.exe (its own internal version)
but it is not the default.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi folks,
first of all: great set of tools and thanks to all developers and contibutors.
I'm currently working with dd.exe from the coreutil package to write to large
files on Windows 2003 Server.
Problem is file write throughput degrades massivly after some time from about
40 megabyte per second to around 4 megabyte per second (steady decay over
aprox. 24h).
This is bad since i deal with a disk image with a size of 1 terrabyte.
On google i found much about syncronous file writes beeing the root cause for
such throughput degradations.
So i was pleased to find the nonblock-flag with dd.exe.
But my tests show there is no difference when using oflag=nonblock, not in
file creation patterns (as shown by Process Monitor) nor in throughput.
Even when looking at the source code (dd.c) I found no substancial
implications using or omitting oflag=nonblock.
Any thoughts on this topic?
I just want to transfer my 1 TB big disk image from a linux box to my windows
box to try out some propriatary XFS undelete tools but it's taking me days to
figure that out. Connecting the hard drives to my win. box is no option since
it's a md-tools raid.
You have an image file of your linux drive on your windows box? If I was doing
testing like that I would boot the image in a virtual machine. I like vmware
workstation because I can take snapshots and if I choose regress to a
snapshot. Snapshots become useless if you try to increase the size of the
virtual disk though, and they take up a lot of space.
re degradation over time, I have experienced that (not specific to dd or
gnuwin) but never by so much. I can't attribute the cause to any particular
thing. I'm interested in what solution you find to that problem. You could try
another version of dd, available here:
http://www.chrysocome.net/dd
I use version 0.5.
7efcd6af6a0fda490b42e0ed4c5aa969079040d1 *dd.exe
The usage is slightly different, and depending on the version it reports
different statistics.
Note that in the 0.6 betas:
--progress output is in the same unit as bs is specified with
As opposed to the way it is 0.5, reporting in bytes.
A note of caution (for anyone) that you could totally decimate your hard
drive if you don't know what you're doing with dd, or setting block size, or
if you don't understand the way windows object links and drive letters can
change. for example windows assigns volume4 and drive letter C to my main
windows partition when I boot with my raid plugged in, but when I boot without
the raid plugged in it assigns volume2 and drive letter C.
]GUID[
link to \?\Device\HarddiskVolume2
fixed media
Mounted on \.\c:
So you'd want to use a combination of winobj,, disk management console, dd
--list, etc so you can confirm what you're writing to. It's a mistake to
assume, oh, well, I always image to volume 5 or whatever so I'll just do that.
Since this task cannot be accomplished practically by using DD.exe directly I
suggest you try using drive imaging software, specifically Clonezilla:
http://clonezilla.org/
Even if you create an image with no compression at all (to save time) it will
break it up into pieces of less than 2GB each. You want to create a Clonezilla
Live CD. Warning: if you decide to select LZMA compression the job may run all
day or longer.
Then of course when you copy the drive image to Windows Server 2003 you will
have to restore the image again using Clonezilla.
Note: the program can be configured to use DD.exe (its own internal version)
but it is not the default.