SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have successfully upgraded my Slackware 14.0 system to 14.1, but now I am facing a severe degradation in disk write speed, file copies go along with about 5 MB/s.
Reads, OTOH, look OK, when I copy to /dev/null or to a network drive, I see "normal" speeds.
Looks like something fundamental has changed in the 14.1 system, but I have no real idea where to look, the reason could be at every level: HW driver, LVM, filesystem. My main suspect would be the ext4-filesystem, does anybody know recent changes there?
Some data about my disk situation:
From lspci:
00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
Timing cached reads: 24918 MB in 1.99 seconds = 12491.03 MB/sec
Timing buffered disk reads: 614 MB in 3.01 seconds = 204.27 MB/sec
fdisk -l /dev/sda
Disk /dev/sda: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x0001f80b
Device Boot Start End Blocks Id System
/dev/sda1 2048 104859647 52428800 83 Linux
/dev/sda2 104859648 109053951 2097152 82 Linux swap
/dev/sda3 109053952 3907029167 1898987608 8e Linux LVM
Look into Advanced Format feature on the disk drive.
When the logical size is less than the physical size, apparently speed is a casualty.
Partition boundaries should be divisible by 8, which yours are not, to prevent problems.
Lots of info about this on the Western Digital and Seagate sites. You clearly have a 4K physical sector and a 512byte logical.
Get those partition boundaries aligned for starters.
Yeah, this is obviously one of these disks.
*But*:
I see that the partitions boundaries *are* divisible by 8.
I think, this has been done automagically by the Linux partition tools when I began to use this disk half a year ago.
And this would have been a problem right from the beginning and not started now with the 14.1 upgrade.
That's the last time I'll use the microsoft calculator on my office PC to divide by 8.
I stayed with 14.1 and changed my disk drive to a 512/512 and things got better for me regarding speed. Better, but not good enough in other areas.
I am thinking of downgrading to 14.0. Too many things seem to be broken in 14.1 for my taste. For instance, I use the client server features in X windows and can't seem to make it work in 14.1.
Good Luck, and I will watch for other contributor's ideas about your problem.
I have meanwhile setup a (LVM) test partition on this disk and I see already only 5-7 MB/s when writing to the raw block device.
I have also made the same experiments with some external USB disks and get: read 30 MB/s write 2-5 MB/s.
So it is beginning to look to me as if something general in some lower disk IO level is going wrong. And I think this (bug?) is triggered by something special in my system configuration, as nobody else seems to have the problem (various searches in the net brought nothing similar).
Thanks, this looked interesting, because it could have been one of these cases where a default might have been changed silently in a newer kernel version but it did not have any effect.
I noticed another thing which looks different as it used to be, regarding kernel memory usage:
Code:
total used free shared buffers cached
Mem: 16585240 10533272 6051968 0 368408 4772448
Isn't it so that the Linux kernel has the tendency to use all available main memory for buffers and caches?
I have the feeling that it does not do this currently on my system.
And not enough buffer storage could also cause slowdowns.
From the 'hdparm' command this HDD seems to be a very new, high performance one, am I right ? I just bought a new one (Seagate Barracuda 1TB) with slightly less performance than yours according to hdparm.
Code:
bash-4.2# hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 30494 MB in 1.99 seconds = 15358.98 MB/sec
Timing buffered disk reads: 484 MB in 3.01 seconds = 161.05 MB/sec
bash-4.2$ dd if=/dev/zero of=file bs=4M count=1000 conv=fdatasync
1000+0 records in
1000+0 records out
4194304000 bytes (4.2 GB) copied, 26.9838 s, 155 MB/s
Maybe try running a SMART long test using smartctl and see if the HDD passes. I'm not sure how to explain 5 MB/s write speed on a new HDD.
From the 'hdparm' command this HDD seems to be a very new, high performance one, am I right ? I just bought a new one (Seagate Barracuda 1TB) with slightly less performance than yours according to hdparm.
Yes, it is a similar disk, a 2TB Seagate Barracuda named ST2000DM001-9YN1
Quote:
Originally Posted by metaschima
Maybe try running a SMART long test using smartctl and see if the HDD passes. I'm not sure how to explain 5 MB/s write speed on a new HDD.
I still think, this is not the real disk speed, see my next message for the current state of research.
First, I seem to have fallen again into a classical trap of spurious correlation, when I thought that the Slackware 14.1 upgrade was the cause for my problem.
Following this track I had now re-installed the kernel files of the previous Slackware version, but did not really get the expected improvements. Only the necessary reboots changed something, I have now similar results with both kernel versions. The write speed is still not fast, but tolerable, no longer inconvenient.
The actual figures are now:
12 MB/s with the kernel 3.2.29
14 MB/s with the kernel 3.10.17
And I see the same speed with my internal SATA disk and several external USB disks. !!!!
Therefore I still believe that it is not a problem with the disks as such, but something in the Linux low level disk IO, buffer handling, bus access or whatever.
For the moment I can live with the situation, I have all my usual programs running and so far the speed has not gone down again, let's see how it develops in the coming days.
I remember someone complaining of unexplained low HDD throughput and it turned out to be vibration or movement as the main cause. If this is a laptop try putting it on a solid surface.
I still recommend running the SMART test, as a HDD will slow down before it breaks.
I remember someone complaining of unexplained low HDD throughput and it turned out to be vibration or movement as the main cause. If this is a laptop try putting it on a solid surface.
Mine is a classical desktop tower standing firmly on the floor.
Quote:
Originally Posted by metaschima
I still recommend running the SMART test, as a HDD will slow down before it breaks.
Hmm, should do no damage. Could you elaborate a bit? How would I go about to run such a test? Linux smartmontools? Is this a non-destructive test which can be done in the running system?
to check the results. The test can be done on a running system without problems. However, try keeping disk usage to a minimum if you want the test to be done on time, otherwise it will take longer. It takes longer on a larger disk. For example it takes 2 hours on a 1TB disk.
The test can be done on a running system without problems. However, try keeping disk usage to a minimum if you want the test to be done on time, otherwise it will take longer. It takes longer on a larger disk. For example it takes 2 hours on a 1TB disk.
Thanks for the smart hints On my disk it took nearly 4 hours. I let it run over night and here are the results:
Code:
smartctl -l selftest /dev/sda
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 5932 -
# 2 Short offline Completed without error 00% 3 -
I think this rules out hardware problems with the disk as such.
So again I suspect some strange Linux kernel errors triggered by my configuration.
Funny thing is that the PC really has abundant resources for everything (it was on purpose bought like that
and should be blatant fast.
Intel Quad-Core i7-3770 CPU (8 virtual CPus)
16GB RAM
2TB SATA-III disk
and as far as I see in the startup logs all the disk goodies are enabled (UDMA, AHCI, NCQ).
My current suspects go into the direction multiprocessing, memory management.
The kernel runs in 32-bit PAE mode, because for various reasons I did not (and still do not) want a full 64-bit system.
I will try to make some tests in a quiet hour with other Linux Live CDs and other kernel options (non-SMP, non-PAE, 64-bit) to see if these make any difference.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.