lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <452A5115.27596.1451223@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
Date:	Mon, 09 Oct 2006 13:39:34 +0200
From:	"Ulrich Windl" <ulrich.windl@...uni-regensburg.de>
To:	linux-kernel@...r.kernel.org
Subject: Q: I/O to block devices

Hello!

I'm surprised: To my knowledge I/O to block devices is synchronous (at least write 
I thought), but:

Trying to sort my Compact Flash cards according to speed I did these tests:
1. Plug in card
2. dd if=/dev/sda of=disk_file
3. Record numbers printed for reading the card (they roughly correspond to those 
of "hdparm -t")
4. dd of=/dev/sda if=disk_file
5. Record the numbers printed for write speed

At that time I realized that write was terribly fast; way too fast. When unpluggin 
the card, replugging the card, and redoing step 4. and 5., the speed was as 
expected.

Now the first big question: Does the Linux kernel suppress writes if it knows the 
data are already on the block device? That seems to be the only possible 
explanation for that.

Then we all know that sync writes suddenly became very slow in the near past. When 
using "oflag=dsync" for the dd command in step 4., the data rate was as low as 
22kB/s (!!!). I would expect unbuffered writes with a speed of at least 500kB/s.
Now the second big question: Where did I/O speed go?

If some kind sould would answer, or point me to an answer, that would be very much 
appreciated (Please CC: to me, I'm not subscribed here).

The system used for testing was SuSE Linux 10.1 with a built-in USB 2.0 card 
reader, and the rest of the system is definitely not the reason for this type of 
slowdown.

Regards,
Ulrich

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ