"[email protected]" <[email protected]> wrote: > >> Now that is a 1 to 5 performance gap !! > >> Any ideas about how to explain this ? > >> > > > > Are you sure that linux has actually written the data to disk > > when the dd has returned? In most cases (esp with such > > a small amount of data) linux has the data in it's buffer > > cache and *not* on the disk. > > > dd on linux with /dev/zero does a little trick where they don't actually do > any copies. Try adding "conv=ascii" to the dd command.
If this was true, then dd in Linux would not be usable because it does not what dd is expectec to do. >From my experiences, filesystems on Linux are slow and Linux tries to create the impression that is is fast. Many people unpack the Linux kernel tar archive and call this a "benchmark". If you carefully check disk access during the time when gnu tar is "working", you see that the writes to disk start abter gnu tar finished, so the time for this tar run is completely meanlingless. If you use star for this task, you notice that star (by default) runs 4x longer because star calls fsync(2) at the end of each extracted file. If you call star -x -no-fsync it runs at least at the speed of gnu tar. It may be a good idea to check the disk access and to call sync(1) after the dd test..... Jörg -- EMail:[email protected] (home) Jörg Schilling D-13353 Berlin [email protected] (uni) [email protected] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily _______________________________________________ opensolaris-discuss mailing list [email protected]
