Today, I'm learning how to use dd. A website showed me how to use this command to make an image of a floppy, like this.

dd bs=2x80x18b if=/dev/fd0 of=/tmp/floppy.image

I thought I'd do a little benchmark between dd and cp, so I gave dd to 'time' as a parameter. When I went to time my cp command...

time cp /dev/fd0 /tmp/floppy1.image

...it seemed to be creating the image from a temp file and not even checking to see if I had the same disk in the drive or not.

I'm running Red Hat 6.0. Does anybody know where it would have dropped the temp file (other than /tmp/floppy.image)? How can I keep this from happening again.

Quite frankly, this sounds like a typical Windows move. The OS doing what it thinks is more efficient so I don't have to worry about making a decision. If I refer to /dev/fd0, it should pull the input from /dev/fd0, not from RAM or the HDD, right?

BTW, if anybody's curious, I timed the cp on another PC in our data center with identical hardware and here are my results. Of course, it would be more reliable to try this on the same PC.

cp - 1:13:05
dd - 1:12:92

I'm sure that with large amounts of data, the difference would be more significant.

cheers,
florestan

The difference in times is probably due to Linux using a cache for disk buffers.

when I performed the cp immediately after performing dd on the same PC, it copied from RAM or swap or some other temp file somewhere else istead of from /dev/fd0. I want to make sure it copies from /dev/fd0. Anybody know how to do that?

Only when I performed the cp operation on another machine with the same hardware did I actually get my time of 1.13.05. The time for cp on the original machine was, obviously, much shorter because it didn't go out to the disk. I'm not really concerned with why cp takes more time than dd. I need to know why cp didn't go out to the floppy drive when it was supposed to.

Probably when cp issued the reads the floppy data was still in the cache buffers so Linux passed the cache data to cp without having to physically read the floppy.

Check this out. In the same scenario as before. I tried popping the disk out of the drive in between my dd and cp operations, and cp read from the floppy. I think it's really interesting that Linux doesn't even read the TOC on the disk. I always thought that the floppy eject was a purely mechanical thing, and that the OS couldn't tell whether there was a disk in the drive or not without trying to read. This has got to be part of the kernel, right? I know I'm totally geeking out on this one thing, but I'm kind of new to Unix-type OSs, and I'm just really fascinated by how Linux does things.

I'm gonna try my little experiment again, just to make sure.

You need to use the mount and umount commands so that the kernel will sync the cache with the disk. If you don't do a umount then you could lose data in the cache that hasn't been written to the floppy.

If you yank the floppy without doing an umount, yes the kernel will continue blithely to use the cache data from that floppy.

That said, try this experiment:
Try making a distinction bewteen data sets. cp only one data set. Then yank the floppy. Then cp the same data set again. Then cp a floppy data set that is not in the cache.

To all the people who're talking about mounting disks: florestan is bypassing mounting and working directly on the device file to make a disk image. Try reading the question :P


What kernel version are you using? I have absolutely no idea why the kernel should cache data when trying to produce a disk image in this manner; caching should only occur when you mount the disk and access it in the normal way. I can't reproduce the same problem here. And yes, if what you're describing is what's happening then it is particularly braindead behaviour.

Try this instead and see if you get the same problem:

Caching doesn't work by file. It works by physical disk block. If the block has been read recently enough it is in the cache.

It's the stock kernel that comes with Red Hat 6.0: 2.2.5 I'll try this at home where I have Red Hat 8.0 and see if the 2.4 kernel does the same. The machines I'm playing with today are in a little lab I've set up in my company's data center.

tried the cat suggestion and got the same result. I even did a diff on the two files that resulted and they came out the same (well... not diferent, I guess).

Like I said, I'm gonna see if 2.4 yields the same results, although I bet not, if y'all are running a 2.4 kernel.

I'm having fun, R U?

It certainly sounds to me like an obscure bug in your kernel, as what you're experiencing certainly isn't expected behaviour.