[opensuse] Slow file copying on openSUSE 12.3
I have done an installation of a new openSUSE 12.3 system. Amongst the odd problems I am having is slow file copying. It makes no difference what physical drives are involved. Copying an 80 MB takes 15-20 seconds. Bigger files taks correspondingly longer. It makes no difference if the copy is to the same directory or to a different partition or even a different disk. On a different 12.3 install with similar (not the same) hardware, the copy takes less than one second. Copying over the network to a computer in another city is faster... Copying to /dev/null is fast as expected. So it seems that it is the writing to a disk part that is the issue. The file systems are ext4 with the default settings used from installation. The system has these disks: [0:0:0:0] disk ATA WDC WD1000DHTZ-0 04.0 /dev/sda [1:0:0:0] disk ATA WDC WD2000FYYZ-0 01.0 /dev/sdb I see this in /var/log/messages, scsi 0:0:0:0: Direct-Access ATA WDC WD1000DHTZ-0 04.0 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) sd 0:0:0:0: [sda] 4096-byte physical blocks sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA scsi 1:0:0:0: Direct-Access ATA WDC WD2000FYYZ-0 01.0 PQ: 0 ANSI: 5 ACPI: Invalid Power Resource to register! sd 1:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sd 1:0:0:0: [sdb] Attached SCSI disk sda: sda1 sda2 sda3 sd 0:0:0:0: [sda] Attached SCSI disk I do not see any complaints about the disks in the log file. To my eyes all looks as expected. Except for the slow speed. I am not sure what else to look at at this time. Anyone have any pointers? -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
A bit more information. On the slow system: # hdparm -Tt /dev/sdb /dev/sdb: Timing cached reads: 27784 MB in 1.99 seconds = 13934.26 MB/sec Timing buffered disk reads: 468 MB in 3.01 seconds = 155.63 MB/sec # hdparm -Tt /dev/sda /dev/sda: Timing cached reads: 27776 MB in 1.99 seconds = 13930.08 MB/sec Timing buffered disk reads: 584 MB in 3.00 seconds = 194.66 MB/sec On a system acting as expected: # hdparm -Tt /dev/sdb /dev/sdb: Timing cached reads: 6852 MB in 2.00 seconds = 3427.26 MB/sec Timing buffered disk reads: 312 MB in 3.01 seconds = 103.56 MB/sec So at this level they seem to be okay. Not sure what this tells us. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
A bit more information. On the slow system:
# hdparm -Tt /dev/sdb
/dev/sdb: Timing cached reads: 27784 MB in 1.99 seconds = 13934.26 MB/sec Timing buffered disk reads: 468 MB in 3.01 seconds = 155.63 MB/sec
# hdparm -Tt /dev/sda
/dev/sda: Timing cached reads: 27776 MB in 1.99 seconds = 13930.08 MB/sec Timing buffered disk reads: 584 MB in 3.00 seconds = 194.66 MB/sec
On a system acting as expected:
# hdparm -Tt /dev/sdb /dev/sdb: Timing cached reads: 6852 MB in 2.00 seconds = 3427.26 MB/sec Timing buffered disk reads: 312 MB in 3.01 seconds = 103.56 MB/sec
So at this level they seem to be okay. Not sure what this tells us.
So the slow system appears to be noticeably faster than the normal system? What filesystems are in use? How much memory? I notice that both read and write cacheing are enabled - do you really want that? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, August 14, 2013 12:09:25 PM Dave Howorth wrote:
Roger Oberholtzer wrote:
A bit more information. On the slow system: # hdparm -Tt /dev/sdb
/dev/sdb: Timing cached reads: 27784 MB in 1.99 seconds = 13934.26 MB/sec Timing buffered disk reads: 468 MB in 3.01 seconds = 155.63 MB/sec
# hdparm -Tt /dev/sda
/dev/sda: Timing cached reads: 27776 MB in 1.99 seconds = 13930.08 MB/sec Timing buffered disk reads: 584 MB in 3.00 seconds = 194.66 MB/sec
On a system acting as expected: # hdparm -Tt /dev/sdb
/dev/sdb: Timing cached reads: 6852 MB in 2.00 seconds = 3427.26 MB/sec Timing buffered disk reads: 312 MB in 3.01 seconds = 103.56 MB/sec
So at this level they seem to be okay. Not sure what this tells us.
So the slow system appears to be noticeably faster than the normal system?
Yep.
What filesystems are in use? How much memory? I notice that both read
ext4, 32 GB RAM
and write cacheing are enabled - do you really want that?
It is the default as set up by the install. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
and write cacheing are enabled - do you really want that?
It is the default as set up by the install.
Just saying, write cacheing can be dangerous. Depends what you're doing. In other news, I noticed that both of the disks reports 512 B logical blocks, but one reports 4096 B physical blocks. ISTR there were/are some issues with how some filesystems deal with such combinations and alignment, and also some issues with some drives lying about what size blocks they have. Trying different filesystems, as already suggested and/or different drives seem like good next steps to me. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, August 14, 2013 02:08:12 PM Dave Howorth wrote:
Roger Oberholtzer wrote:
and write cacheing are enabled - do you really want that?
It is the default as set up by the install.
Just saying, write cacheing can be dangerous. Depends what you're doing.
In other news, I noticed that both of the disks reports 512 B logical blocks, but one reports 4096 B physical blocks. ISTR there were/are some issues with how some filesystems deal with such combinations and alignment, and also some issues with some drives lying about what size blocks they have. Trying different filesystems, as already suggested and/or different drives seem like good next steps to me.
Since the problem is on / as well as an additional disk, a reinstall would be needed. But of course I can check the non-system disk to see if that helps on that one. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
Roger Oberholtzer wrote:
and write cacheing are enabled - do you really want that?
It is the default as set up by the install.
Just saying, write cacheing can be dangerous. Depends what you're doing.
It is really odd that the disk would have it enabled by default. -- Per Jessen, Zürich (21.9°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: <alpine.LNX.2.00.1308141941210.305@minas-tirith.valinor> El 2013-08-14 a las 16:05 +0200, Per Jessen escribió:
Dave Howorth wrote:
Roger Oberholtzer wrote:
and write cacheing are enabled - do you really want that?
It is the default as set up by the install.
Just saying, write cacheing can be dangerous. Depends what you're doing.
It is really odd that the disk would have it enabled by default.
cer@minas-tirith:~> zgrep "DPO or FUA" /var/log/messages*bz2 /var/log/messages-20130808.bz2:<0.5> 2013-06-10 15:56:31 minas-tirith kernel - - - [22829.008745] sd 7:0:0:1: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA /var/log/messages-20130808.bz2:<0.5> 2013-06-10 15:56:32 minas-tirith kernel - - - [22830.011473] sd 7:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Also set by default, and it is a laptop on 11.4. It is an external disk, I think, which produces that entry. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlILwb0ACgkQja8UbcUWM1yiBQD9FpoWkv2ftx8egOoPLCCLs/Z5 KxfYcphBdwnGumjyVYUA/1eONEMX7JyMAT203Js3vZDXqkQbQlapiATBY611bjuE =CbQ3 -----END PGP SIGNATURE-----
On Wednesday, August 14, 2013 04:05:20 PM Per Jessen wrote:
Dave Howorth wrote:
Roger Oberholtzer wrote:
and write cacheing are enabled - do you really want that?
It is the default as set up by the install.
Just saying, write cacheing can be dangerous. Depends what you're doing.
It is really odd that the disk would have it enabled by default.
You mean the write cache on the disk itself? Wouldn't/couldn't openSUSE be controlling that? Otherwist, I guess it is whatever the hard disk maker has as delivered default. I am guessing that this is dangerous in the event of a power loss. At any other times? -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Wednesday, August 14, 2013 04:05:20 PM Per Jessen wrote:
Dave Howorth wrote:
Roger Oberholtzer wrote:
and write cacheing are enabled - do you really want that?
It is the default as set up by the install.
Just saying, write cacheing can be dangerous. Depends what you're doing.
It is really odd that the disk would have it enabled by default.
You mean the write cache on the disk itself?
Yep.
Wouldn't/couldn't openSUSE be controlling that?
I don't think so, no - I don't know of anywhere in openSUSE where you're able to specify it.
Otherwist, I guess it is whatever the hard disk maker has as delivered default.
Right, and that is odd.
I am guessing that this is dangerous in the event of a power loss. At any other times?
No, power loss is the critical event - as far as Linux is concerned, the data has been written when the disk confirms, but until the data has actually made it to a platter, a power loss would be bad. -- Per Jessen, Zürich (15.1°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday, August 15, 2013 08:13:02 AM Per Jessen wrote:
Wouldn't/couldn't openSUSE be controlling that?
I don't think so, no - I don't know of anywhere in openSUSE where you're able to specify it.
Via hdparam perhaps? Another person in this thread reported that their disk also has write cache enabled. And that was on a laptop where power loss is more common than a system on a UPS. So maybe more poeple have this than expect. I just checked a few more 12.3 systems, and I see things like: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 4:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 8:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 9:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 12:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA In fact, I do not see any systems locally where disk write cache is not enabled. There is a mix of Seagate and Western Digital SATA disks. My oldest 10.0 system (soon to be replaced...) has write cache enabled for an old Seagate ATA disk. hdparm -I /dev/hda Commands/features: Enabled Supported: * READ BUFFER cmd * WRITE BUFFER cmd * Host Protected Area feature set * Look-ahead * Write cache * Power Management feature set Security Mode feature set * SMART feature set * FLUSH CACHE EXT command * Mandatory FLUSH CACHE command * Device Configuration Overlay feature set * 48-bit Address feature set SET MAX security extension * DOWNLOAD MICROCODE cmd * SMART self-test * SMART error logging Perhaps I am looking at this in the wrong way? -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Thursday, August 15, 2013 08:13:02 AM Per Jessen wrote:
Wouldn't/couldn't openSUSE be controlling that?
I don't think so, no - I don't know of anywhere in openSUSE where you're able to specify it.
Via hdparam perhaps?
Yes, but I was more thinking of where you'd go in yast or /etc/sysconfig/* to set it.
Another person in this thread reported that their disk also has write cache enabled. And that was on a laptop where power loss is more common than a system on a UPS.
On a system with a UPS, having write cache enabled is normal. On a laptop, well, it works pretty much like a system with a UPS. When power is low, it shuts down.
So maybe more poeple have this than expect.
I just checked a few more 12.3 systems, and I see things like: [snip] In fact, I do not see any systems locally where disk write cache is not enabled.
Maybe we're misinterpreting "write cache" in this context, I don't know. -- Per Jessen, Zürich (15.8°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer <roger@opq.se> wrote:
On Thursday, August 15, 2013 08:13:02 AM Per Jessen wrote:
Wouldn't/couldn't openSUSE be controlling that?
I don't think so, no - I don't know of anywhere in openSUSE where you're able to specify it.
Via hdparam perhaps? Another person in this thread reported that their disk also has write cache enabled. And that was on a laptop where power loss is more common than a system on a UPS. So maybe more poeple have this than
expect.
I just checked a few more 12.3 systems, and I see things like:
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, <snip>
Perhaps I am looking at this in the wrong way?
I think Per is wrong. Write cache enabled on a sata drive is normal. But it is small and the drive itself can flush it during a power off event. Fyi: per Linus, disk cache is internally organized in track size chunks. A typical track can hold 1mb, so a 8mb cache on the drive controller can only hold 8 tracks at a time and that is shared by read and write. Thus at max when power dies the drive needs to seek 8 times and let the disk spin one rotation. And the seeks will be done in elevator order, so its not 8 worst case seeks. So that can be done in about 100 millisecs. Thus a capacitor to hold a tenth of a seconds power is all the drive needs. I suspect Per is used to enterprise gear with bigger caches. The bigger the cache the more dangerous it is. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
I think Per is wrong. Write cache enabled on a sata drive is normal. But it is small and the drive itself can flush it during a power off event.
Fyi: per Linus, disk cache is internally organized in track size chunks. A typical track can hold 1mb, so a 8mb cache on the drive controller can only hold 8 tracks at a time and that is shared by read and write. Thus at max when power dies the drive needs to seek 8 times and let the disk spin one rotation.
And the seeks will be done in elevator order, so its not 8 worst case seeks. So that can be done in about 100 millisecs. Thus a capacitor to hold a tenth of a seconds power is all the drive needs.
I _was_ wondering if the disk would have something like that.
I suspect Per is used to enterprise gear with bigger caches. The bigger the cache the more dangerous it is.
Terabyte size drives often come with 64Mb cache, but it's probably still only 8Mb for writing. -- Per Jessen, Zürich (22.9°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-08-15 at 08:27 -0400, Greg Freemyer wrote:
Fyi: per Linus, disk cache is internally organized in track size chunks. A typical track can hold 1mb, so a 8mb cache on the drive controller can
1 MB per track? Then a 1 TB disk would have a million tracks? Surely a track is bigger. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEUEARECAAYFAlINE8MACgkQtTMYHG2NR9XghQCY/5Tdk6qs8c0jdok5JFkodsR8 VgCfZZRzzSS9/f19PeZdzGOydzqf+VE= =mOLE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Aug 15, 2013 at 1:45 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
Fyi: per Linus, disk cache is internally organized in track size chunks. A typical track can hold 1mb, so a 8mb cache on the drive controller can
1 MB per track? Then a 1 TB disk would have a million tracks? Surely a track is bigger.
Yes and no. If a 1 TB drive has 4 heads, then it 250,000 cylinders. But a cylinder would have 4 tracks, so yes it is 1 million tracks total, but only 250,000 per platter surface. I'll let you do the math, but this is how I do it: A 7200 RPM disk does 120 revolutions per second. At its fastest speed it is reading (or writing) data continuously, so that is 120 tracks per second continuous at its fastest A fast SATA drive transfers about 120 MB/second. Thus 1 track = 1MB. If the bottleneck is something other than how fast the media moves underneath the disk head, then my analysis is wrong, but I really do think that the limiting factor is how fast the drive is spinning. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-08-15 at 17:40 -0400, Greg Freemyer wrote:
On Thu, Aug 15, 2013 at 1:45 PM, Carlos E. R. <> wrote:
1 MB per track? Then a 1 TB disk would have a million tracks? Surely a track is bigger.
Yes and no. If a 1 TB drive has 4 heads, then it 250,000 cylinders. But a cylinder would have 4 tracks, so yes it is 1 million tracks total, but only 250,000 per platter surface.
I'll let you do the math, but this is how I do it:
A 7200 RPM disk does 120 revolutions per second.
At its fastest speed it is reading (or writing) data continuously, so that is 120 tracks per second continuous at its fastest
Not possible. Moving the head from one track to the next takes some time It moves an stimate (it is an analogic voice coil), then reads track metadata to learn where it is, and if it is not where it should, it moves again. Acording to the datasheet of the Seagate Barracuda 7200.12 (because I have it at hand) the track to track time is 1 mS (average time is 8.5 mS). 1 mS seek time, plus 8.3 mS read time per track (1 revolution), that is 9.3 mS per track. That is 107 tracks per second maximum :-) However, the same datasheet says: Track density: 236 ktracks/in avg If the platter has 2" and something usefull surface radius, thats about .5·10⁶ tracks per platter side, which is even more than the number you said, so you are about right and I wasn't. But it surprises me the high number of tracks and the low linear density (1 meg per track?), or I'm looking at it wrong. I have two other figures: Recording density: 1413 kbits/in max Areal density: 329 Gbits/in2 avg At a 2" radius, that's 6,28· of circunference, so that's 8,8781×10⁶kbits, or about 1,109 MB So you are right :-) - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlINWlEACgkQtTMYHG2NR9WO+QCfeGO+ndXtXgMHGWVVcDR/uBNI kPYAnjFJPoWydBi4mj8mjs4Z9P7N+SDx =L/s7 -----END PGP SIGNATURE-----
On Thu, Aug 15, 2013 at 6:46 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
If the platter has 2" and something usefull surface radius, thats about .5·10⁶ tracks per platter side, which is even more than the number you said, so you are about right and I wasn't.
A 3 1/2 inch across drive with a 2 inch useful radius. Where do you buy your drives? I need some of those! Seriously, I'd say a desktop 3 1/2 inch drive only has about 1 inch of useful radius. There's dead space in the middle that is about 1 inch in diameter (1/2" radius) and at least an 1/4th of an inch dead at the edge between the chassis / air / unused platter edge. fyi: I don't have a dead / disassembled drive handy to actually measure so I'm going from memory. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-08-16 16:00 (GMT-0400) Greg Freemyer composed:
A 3 1/2 inch across drive with a 2 inch useful radius. Where do you buy your drives? I need some of those!
Seriously, I'd say a desktop 3 1/2 inch drive only has about 1 inch of useful radius. There's dead space in the middle that is about 1 inch in diameter (1/2" radius) and at least an 1/4th of an inch dead at the edge between the chassis / air / unused platter edge.
fyi: I don't have a dead / disassembled drive handy to actually measure so I'm going from memory.
I always have platters from '3.5"' HDs laying about. :-) The one in hand actually measures just short of 3.75" across. The hole in the middle looks like 31/32". The width available for heads to to stroke is about 1.375" gross. So, usable width of the surface of an inch or a bit more would seem about right. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2013-08-16 at 16:00 -0400, Greg Freemyer wrote:
On Thu, Aug 15, 2013 at 6:46 PM, Carlos E. R. <> wrote:
If the platter has 2" and something usefull surface radius, thats about .5·10⁶ tracks per platter side, which is even more than the number you said, so you are about right and I wasn't.
A 3 1/2 inch across drive with a 2 inch useful radius. Where do you buy your drives? I need some of those!
I'm not used to calculate in inches. The disk bay is 5¼, so I halved that minus a bit, so I thought that 2" would be the approximate radius. I did not remember that hard disks are labeled as 3.5", lot smaller than the bay - if it were centimeters it would mean something to me. A number in inches is just a number to me, has no meaning. :-}
Seriously, I'd say a desktop 3 1/2 inch drive only has about 1 inch of useful radius. There's dead space in the middle that is about 1 inch in diameter (1/2" radius) and at least an 1/4th of an inch dead at the edge between the chassis / air / unused platter edge.
fyi: I don't have a dead / disassembled drive handy to actually measure so I'm going from memory.
Me neither... The only disks totally broken I have are two laptop units. Actually 1 disk... Perhaps I have a 3.5" somewhere. Some people made wall clocks with them :-) - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIOmX0ACgkQtTMYHG2NR9UaBACeIDIC2XshZm8dqsOlpbtG5xve N3gAnRw5JOGKQcMIBfKl1AFuD7KJ102V =qxWd -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday, 2013-08-16 at 16:00 -0400, Greg Freemyer wrote:
On Thu, Aug 15, 2013 at 6:46 PM, Carlos E. R. <> wrote:
If the platter has 2" and something usefull surface radius, thats about .5·10⁶ tracks per platter side, which is even more than the number you said, so you are about right and I wasn't.
A 3 1/2 inch across drive with a 2 inch useful radius. Where do you buy your drives? I need some of those!
I'm not used to calculate in inches.
The disk bay is 5¼,
That is a CDROM bay I think.
I did not remember that hard disks are labeled as 3.5", lot smaller than the bay
2.5" / 3.5" is exactly the width of the harddrive. The bays and trays I work with are also that size. -- Per Jessen, Zürich (21.1°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
No, power loss is the critical event - as far as Linux is concerned, the data has been written when the disk confirms, but until the data has actually made it to a platter, a power loss would be bad.
Isn't the purpose of journaling to prevent this sort of problem? If it's not in the journal, it hasn't been written. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
Per Jessen wrote:
No, power loss is the critical event - as far as Linux is concerned, the data has been written when the disk confirms, but until the data has actually made it to a platter, a power loss would be bad.
Isn't the purpose of journaling to prevent this sort of problem? If it's not in the journal, it hasn't been written.
It might be in the journal, but still not written - when it's in the controller or disk cache. -- Per Jessen, Zürich (24.5°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Aug 15, 2013 at 10:34 AM, James Knott <james.knott@rogers.com> wrote:
Per Jessen wrote:
No, power loss is the critical event - as far as Linux is concerned, the data has been written when the disk confirms, but until the data has actually made it to a platter, a power loss would be bad.
Isn't the purpose of journaling to prevent this sort of problem? If it's not in the journal, it hasn't been written.
But you have to ensure the journal write get to disk, not stuck in a cache. I'm pretty sure XFS and ext4 both use "barriers" to make that happen as appropriate. But those barriers have to be supported all the way to the drive. mdraid use to drop them on the floor. Some sata drives drop them on the floor. But with most setups barriers work and the journal can be relied on. ext4 defaults to metadata journaling, but not data journalling. That means your filesystem structure is protected by barriers, but the content of your files is not. XFS for years was renowned for protecting files full of nulls for this reason. That has been fixed in XFS as far as I know for 5+ years now. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
But with most setups barriers work and the journal can be relied on. ext4 defaults to metadata journaling, but not data journalling.
---- That's the difference between write-back (data done after journaled and after return success to user) vs. write-through (data is written through to disk , synchronously with the journal (and /or before returning to user, depending on usage context). The read cache has other requirements. I constantly see: [sda] Write cache: enabled, read cache: disabled, doesn't support DPO or FUA on some of my disks on bootup.
That means your filesystem structure is protected by barriers, but the content of your files is not. XFS for years was renowned for protecting files full of nulls for this reason.
I am pretty sure this wasn't the reason -- but had more to do with XFS's security requirement for Trusted Irix, which required, in-its-design, for files with "unwritten extents" to be marked as uninitialized -- so if they were mapped in the middle of a file, they'd be zero'd before being handed to the user. Conversely -- the opposite behavior, which wasn't as famous was seen on most other file systems -- having random garbage show up in a file -- that usually corresponded to a file fragment of some previously deleted file. Only in a minority of cases where such a file was a text file, would it be noted as "file data from a foreign file". Even then, unless it belongs to another user and contained something notable, someone might have thought it was text from one of their files that ended up as garbage in the middle of some other file...
That has been fixed in XFS as far as I know for 5+ years now.
Having used XFS on linux on work and home PC's since 2001, I'm pretty sure it was never the issue people think it was but was more the case of them not noticing equivalent cases of random-text in other file systems... unless those systems did 'write-through' which gives noticeably slow interactive performance. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Aug 14, 2013 at 6:37 AM, Roger Oberholtzer <roger@opq.se> wrote:
A bit more information. On the slow system:
# hdparm -Tt /dev/sdb
/dev/sdb: Timing cached reads: 27784 MB in 1.99 seconds = 13934.26 MB/sec Timing buffered disk reads: 468 MB in 3.01 seconds = 155.63 MB/sec
# hdparm -Tt /dev/sda
/dev/sda: Timing cached reads: 27776 MB in 1.99 seconds = 13930.08 MB/sec Timing buffered disk reads: 584 MB in 3.00 seconds = 194.66 MB/sec
On a system acting as expected:
# hdparm -Tt /dev/sdb /dev/sdb: Timing cached reads: 6852 MB in 2.00 seconds = 3427.26 MB/sec Timing buffered disk reads: 312 MB in 3.01 seconds = 103.56 MB/sec
So at this level they seem to be okay. Not sure what this tells us.
Look in /var/log/warnng for media errors on the drives. That can really slow things down. If nothing you're going to have to tell us about the storage stack at a minimum. (volumes / raid / filesystem type) Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, August 14, 2013 07:27:51 AM Greg Freemyer wrote:
On Wed, Aug 14, 2013 at 6:37 AM, Roger Oberholtzer <roger@opq.se> wrote:
A bit more information. On the slow system: # hdparm -Tt /dev/sdb
/dev/sdb: Timing cached reads: 27784 MB in 1.99 seconds = 13934.26 MB/sec Timing buffered disk reads: 468 MB in 3.01 seconds = 155.63 MB/sec
# hdparm -Tt /dev/sda
/dev/sda: Timing cached reads: 27776 MB in 1.99 seconds = 13930.08 MB/sec Timing buffered disk reads: 584 MB in 3.00 seconds = 194.66 MB/sec
On a system acting as expected: # hdparm -Tt /dev/sdb
/dev/sdb: Timing cached reads: 6852 MB in 2.00 seconds = 3427.26 MB/sec Timing buffered disk reads: 312 MB in 3.01 seconds = 103.56 MB/sec
So at this level they seem to be okay. Not sure what this tells us.
Look in /var/log/warnng for media errors on the drives. That can really slow things down.
No messages in /var/log/messages, except like I listed in the op.
If nothing you're going to have to tell us about the storage stack at a minimum. (volumes / raid / filesystem type)
SuperMicro motherboard with Haswell 4C Core i7-4770 3.4G 8M 5GT/s DMI SATA3 disks (1000MB Western Digital Velicoraptor 10K/ 64, 3,5") via intel chipset spec above. ext4 with defaults. Basic partitioning. No LVM or RAID. We have done an openSUSE 12.3 update, and the problem persists. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-08-14 a las 13:58 +0200, Roger Oberholtzer escribió:
SATA3 disks (1000MB Western Digital Velicoraptor 10K/ 64, 3,5") via intel chipset spec above.
Run the long test of smartctl on them. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlILdzwACgkQja8UbcUWM1zzGAD/fWL1p45RelFkTg3kVsn80qH1 9mXUiSNtqsgTOI+defEA/iQZ6BUvs8JqJlI2q4Wv8IpunmajCoETcU5f2ko1384s =BPAY -----END PGP SIGNATURE-----
On Wed, Aug 14, 2013 at 01:58:32PM +0200, Roger Oberholtzer wrote: [ 8< ]
ext4 with defaults. Basic partitioning. No LVM or RAID.
I would try ext3, xfs, or btrfs on the identical hardware and test these. For btrfs see the recent discussion on opensuse-factory too. http://lists.opensuse.org/opensuse-factory/2013-07/msg00314.html
We have done an openSUSE 12.3 update, and the problem persists.
'We have done an openSUSE 12.3 update' = zypper patch or YaST online update? Even if you got the last 12.3 kernel update and all the other fixes your ext4 stays ext4. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On Wednesday, August 14, 2013 02:57:13 PM Lars Müller wrote:
On Wed, Aug 14, 2013 at 01:58:32PM +0200, Roger Oberholtzer wrote: [ 8< ]
ext4 with defaults. Basic partitioning. No LVM or RAID.
I would try ext3, xfs, or btrfs on the identical hardware and test these.
For btrfs see the recent discussion on opensuse-factory too. http://lists.opensuse.org/opensuse-factory/2013-07/msg00314.html
We have done an openSUSE 12.3 update, and the problem persists.
'We have done an openSUSE 12.3 update' = zypper patch or YaST online
zypper up
update? Even if you got the last 12.3 kernel update and all the other fixes your ext4 stays ext4.
I am going to check that the update really updated everythin for which there was an updateg. JIC. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Aug 14, 2013 at 7:58 AM, Roger Oberholtzer <roger@opq.se> wrote:
If nothing you're going to have to tell us about the storage stack at a minimum. (volumes / raid / filesystem type)
SuperMicro motherboard with Haswell 4C Core i7-4770 3.4G 8M 5GT/s DMI
SATA3 disks (1000MB Western Digital Velicoraptor 10K/ 64, 3,5") via intel chipset spec above.
ext4 with defaults. Basic partitioning. No LVM or RAID.
We have done an openSUSE 12.3 update, and the problem persists.
Does dd from the raw device run quickly? ie. dd if=/dev/sdx of=/dev/null count=1000000 That count is 1 million, so with 512 byte blocks that's half a GB. It should take 5 or 10 seconds. If you can destroy the data, what about the speed of writes with dd? If you can't write to the raw device do the above with a file. 1/2 a GB is not too big to fit unless your filesystem is really full. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-08-14 12:37 (GMT+0200) Roger Oberholtzer composed:
A bit more information. On the slow system:
# hdparm -Tt /dev/sdb
/dev/sdb: Timing cached reads: 27784 MB in 1.99 seconds = 13934.26 MB/sec Timing buffered disk reads: 468 MB in 3.01 seconds = 155.63 MB/sec
# hdparm -Tt /dev/sda
/dev/sda: Timing cached reads: 27776 MB in 1.99 seconds = 13930.08 MB/sec Timing buffered disk reads: 584 MB in 3.00 seconds = 194.66 MB/sec
On a system acting as expected:
# hdparm -Tt /dev/sdb /dev/sdb: Timing cached reads: 6852 MB in 2.00 seconds = 3427.26 MB/sec Timing buffered disk reads: 312 MB in 3.01 seconds = 103.56 MB/sec
So at this level they seem to be okay. Not sure what this tells us.
It seems to confirm Dave's allusion to sector misalignment in the partition tables. Are partitions laid out to align with 4k sectors? How was partitioning on the Velicoraptors done (what tool was used to create)? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, August 14, 2013 10:33:31 AM Felix Miata wrote:
On 2013-08-14 12:37 (GMT+0200) Roger Oberholtzer composed:
A bit more information. On the slow system: # hdparm -Tt /dev/sdb
/dev/sdb: Timing cached reads: 27784 MB in 1.99 seconds = 13934.26 MB/sec Timing buffered disk reads: 468 MB in 3.01 seconds = 155.63 MB/sec
# hdparm -Tt /dev/sda
/dev/sda: Timing cached reads: 27776 MB in 1.99 seconds = 13930.08 MB/sec Timing buffered disk reads: 584 MB in 3.00 seconds = 194.66 MB/sec
On a system acting as expected: # hdparm -Tt /dev/sdb
/dev/sdb: Timing cached reads: 6852 MB in 2.00 seconds = 3427.26 MB/sec Timing buffered disk reads: 312 MB in 3.01 seconds = 103.56 MB/sec
So at this level they seem to be okay. Not sure what this tells us.
It seems to confirm Dave's allusion to sector misalignment in the partition tables. Are partitions laid out to align with 4k sectors? How was partitioning on the Velicoraptors done (what tool was used to create)?
The entire disk was set up by openSUSE via KIWI. This aspect of the image is controlled by: <oem-align-partition>true</oem-align-partition> When 'true', Kiwi attempts to align the start sector of the disk partition on a 4K boundary. I am not sure how to verify this. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-08-15 07:34 (GMT+0200) Roger Oberholtzer composed:
Felix Miata wrote:
It seems to confirm Dave's allusion to sector misalignment in the partition tables. Are partitions laid out to align with 4k sectors? How was partitioning on the Velicoraptors done (what tool was used to create)?
The entire disk was set up by openSUSE via KIWI. This aspect of the image is controlled by:
<oem-align-partition>true</oem-align-partition>
When 'true', Kiwi attempts to align the start sector of the disk partition on a 4K boundary.
I am not sure how to verify this.
What is fdisk -l | head output? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 14/08/13 05:24, Roger Oberholtzer escribió:
scsi 1:0:0:0: Direct-Access ATA WDC WD2000FYYZ-0 01.0 PQ: 0 ANSI: 5 ACPI: Invalid Power Resource to register!
^^ what the hell is going on there.. might be related to your problem. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday, August 14, 2013 12:57:05 PM Cristian Rodríguez wrote:
El 14/08/13 05:24, Roger Oberholtzer escribió:
scsi 1:0:0:0: Direct-Access ATA WDC WD2000FYYZ-0 01.0 PQ: 0 ANSI: 5 ACPI: Invalid Power Resource to register!
^^ what the hell is going on there.. might be related to your problem.
SuperMicro BIOS are generally buggy. ACPI is an area that they usually have issues with. The general opinion is that if you experience a problem, be sure to get the latest BIOS. The board in question is only a couple months old. I have not seen a new BIOS. I have run the intel hardware tests (at one point it was part of the openSUSE install) on various boards and there are always many complaints. It makes you wonder if SuperMicro run any similat tests. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Seems that the kernel was NOT updated to the latest, as I had been led to believe. When that was done, write speed looks fine. The previous kernel was current as of July 11 or so when the system was originally installed. The new kernel is from the openSUSE update repo. If anyone is interested, I can post the specific kernel versions. I will have access to the system again tomorrow. -- Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (10)
-
Carlos E. R. -
Cristian Rodríguez -
Dave Howorth -
Felix Miata -
Greg Freemyer -
James Knott -
Lars Müller -
Linda Walsh -
Per Jessen -
Roger Oberholtzer