Slow I/O on Laptop

Hi all!

I have a laptop. And I have very strange hard disk issue: periodically the system freezes (the mouse works, but other programs are not responding), hard disk LED at this moment are on. And that appears only when some more or less intensive work with the hard disk occurs, for example port building, portsnap fetch update, csup /root/stable-supfile.

No errors in /var/log/messages.

In Windows something similar never happens (I'm trying to extract a ports snapshot in Windows).

And when I see gstat on that moment:
Code:
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
    0      0      0      0    0.0      0      0    0.0    0.0| cd0
   91    277      0      0    0.0    277   4187  876.6  110.0| ada0
    0      0      0      0    0.0      0      0    0.0    0.0| ada0s1
    0      0      0      0    0.0      0      0    0.0    0.0| ada0s2
   91    277      0      0    0.0    277   4187  876.7  110.0| ada0s3
    0      0      0      0    0.0      0      0    0.0    0.0| ada0s4
    0      0      0      0    0.0      0      0    0.0    0.0| ntfs/WIN7
    2      0      0      0    0.0      0      0    0.0    0.0| ada0s3a
   88    277      0      0    0.0    277   4187  876.8  110.0| ada0s3b
    1      0      0      0    0.0      0      0    0.0    0.0| ada0s3d
    0      0      0      0    0.0      0      0    0.0    0.0| ada0s3e
    0      0      0      0    0.0      0      0    0.0    0.0| ada0s3f
    0      0      0      0    0.0      0      0    0.0    0.0| ada0s5
    0      0      0      0    0.0      0      0    0.0    0.0| da0

I son't have any similar issues on any other hardware (netbook, laptops, PC), I think there is some problem. What do I need to provide to solve that issue?

There is info on Pastebin:
dmesg, Kernel configuration
uname -a
Code:
FreeBSD MYBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sun May  5 18:08:33 MSK 2013     kirilok@MYBSD:/usr/obj/usr/src/sys/MYBSD  amd64
 
Keep in mind that -CURRENT is a work in progress. It may not be stable or even build at times. I suggest using a -RELEASE or -STABLE.

Please report issues with -CURRENT to the freebsd-current@ mailinglist.
 
Emphasis added to previous remarks:

Maybe it's time to explain again that -CURRENT does not mean what people think it means. If you want the latest and greatest without too much risk, run -STABLE. If you want to nuke your system and possibly your hardware, run -CURRENT, but follow the freebsd-current mailing list. This forum tries to cater to users of supported -RELEASE and -STABLE versions.

In fact, I think I'm going to write this into the Rules and Guidelines.
 
vermaden said:
@ORTO-DOX

CURRENT by default has a lot of debugging options enabled, have you disabled them?

Yes, I'm not 100% FreeBSD professional, but I use that system in various aspects (my own desktop, all my working servers) on FreeBSD, so ofcourse I'm read /usr/src/UPDATING and disable all debug related options. Also I provided my kernel config in the first post.
SirDice said:
Emphasis added to previous remarks:

Maybe it's time to explain again that -CURRENT does not mean what people think it means. If you want the latest and greatest without too much risk, run -STABLE. If you want to nuke your system and possibly your hardware, run -CURRENT, but follow the freebsd-current mailing list. This forum tries to cater to users of supported -RELEASE and -STABLE versions.

In fact, I think I'm going to write this into the Rules and Guidelines.
Yes I know that, and since my laptop is only for me I'm using it in some experimental area. But I installed 9-STABLE first in October 2012, that problem was present at that time, after that I build -CURRENT, and sometimes post problems on that forum and in the mailing list.

HERE (I'm marking it as solved but it is not solved, I'm just mistaken :)
 
portsnap update will write lots of small files onto /dev/ada0. And unless /dev/ada0 is actually an SSD, the result from gstat made perfect sense. In other words, the IOPS of /dev/ada0 is the limiting factor here.
 
But please, tell me why when I do portsnap fetch extract on that laptop with 500 GB SATA AHCI enabled drive and based on Core i5 + 4GB RAM, it freezes (and it extracts some number of ports and freezes, after some seconds again extracts some 20-50 ports and again freezes), but on exactly the same laptop but on Windows when it extracts with WinRAR the same ports tree snapshot it does not freeze?

Also, why on a laptop with PII-266Mhz and 64 MB RAM and 40 GB IDE drive does it extract the ports tree without any freezes?

I think this is absolutely an abnormal situation. Note the problem of disk IOPS. Because when the ports snapshot extracts it does that sequentially, IOPS will be the limiting factor if I try to do in parallel some extract jobs.

I can provide any additional information if needed.
 
You may want to retry this without AHCI mode, some drives do not really play nice with it. Or to put it more bluntly, some vendors should be forced to stick a "Designed for Windows" sticker on harddisks.
 
I've seen a Dell laptop behaving the same way having Windozews on it. The problem was some Southbridge design flaw. The default driver was not aware of that. Google it.
 
HarryE said:
I've seen a Dell laptop behaving the same way having Windows on it. The problem was some Southbridge design flaw. The default driver was not aware of that. Google it.
Thank for way to search, can you @HarryE tell, driver for what is a point of problem?
 
Last edited by a moderator:
Unless the drive is truly a 4K-block "Advanced Format" drive, alignment to 4K blocks does not matter.

If it is an AF drive, block starting numbers must be evenly divisible by 4K. Post the output of gpart show and many of us will be happy to check.
 
Code:
=>       63  976773105  ada0  MBR  (465G)
         63       1985        - free -  (992k)
       2048     204800     1  ntfs  (100M)
     206848  102195200     2  ntfs  (48G)
  102402048         42        - free -  (21k)
  102402090  796917681     3  freebsd  [active]  (380G)
  899319771         37        - free -  (18k)
  899319808   77453312     4  ebr  (37G)
  976773120         48        - free -  (24k)
Thank for the help! There is my gpart show ada0 output.
 
That is a Hitachi Travelstar Z5K500 drive, nominally 500 GB. It is an Advanced Format (4K) drive; good call, @t1066! Slice 3 is FreeBSD, starts at 512-byte block 102402090. So:

(512*102402090)/4096= 12800261.25

Or, since 4096/512=8:

102402090/8= 12800261.25

So we have good news and bad news. The bad news is that the FreeBSD slice is not 4K-aligned, or the calculation above would give an integer.

The good news is that it may be an explanation for the performance lag seen. Maybe not all of it, though. Note that the NTFS partition *is* aligned.
 
Last edited by a moderator:
Writing a response about how to back up, create a new aligned partition, and restore reminded me that this is MBR, and alignment is ugly with MBR.

While the slice is not aligned, the FreeBSD partitions inside it could still be aligned. Please show the output of gpart show ada0s3.
 
It's a shame that FreeBSD insists on sticking to outdated CHS geometry concepts when creating slices under the MBR scheme.

If Microsoft has seen fit to ignore geometry alignment and start their partitions at sensible LBAs, why can't FreeBSD do the same? gpart actively prevents you from doing so. It's not even behaviour that you can override with a switch.
 
gpart(8), or the kernel routines that it uses, sticks to the MBR standard. But the rest of the world has changed, and there is a new standard. I and others have argued that FreeBSD should accept this, but so far it does not. All I can suggest is for people who wish that to change to either enter a PR, mention it on the mailing lists, or both.

Edit: a PR with links to the new 1M-aligned standard and other reasons justifying the change would be good.
 
wblock@ said:
Writing a response about how to back up, create a new aligned partition, and restore reminded me that this is MBR, and alignment is ugly with MBR.

While the slice is not aligned, the FreeBSD partitions inside it could still be aligned. Please show the output of gpart show ada0s3.
That is information: gpart show ada0s3
Code:
=>        0  796917681  ada0s3  BSD  (380G)
          0    2097152       1  freebsd-ufs  (1.0G)
    2097152   62914560       2  freebsd-ufs  (30G)
   65011712   62914560       4  freebsd-ufs  (30G)
  127926272    8388608       5  freebsd-swap  (4.0G)
  136314880  660602800       6  freebsd-ufs  (315G)
  796917680          1          - free -  (512B)
 
ORTO-DOX said:
gpart show ada0
Code:
=>       63  976773105  ada0  MBR  (465G)
         63       1985        - free -  (992k)
       2048     204800     1  ntfs  (100M)
     206848  102195200     2  ntfs  (48G)
  102402048         42        - free -  (21k)
  102402090  796917681     3  freebsd  [active]  (380G)
  899319771         37        - free -  (18k)
  899319808   77453312     4  ebr  (37G)
  976773120         48        - free -  (24k)
gpart show ada0s3
Code:
=>        0  796917681  ada0s3  BSD  (380G)
          0    2097152       1  freebsd-ufs  (1.0G)
    2097152   62914560       2  freebsd-ufs  (30G)
   65011712   62914560       4  freebsd-ufs  (30G)
  127926272    8388608       5  freebsd-swap  (4.0G)
  136314880  660602800       6  freebsd-ufs  (315G)
  796917680          1          - free -  (512B)

Combining both of those:

The FreeBSD slice starts at 512-byte block 102402090. Adding the partition starting blocks inside that slice gives the starting block of the partition on disk. To be aligned, that number must be an even multiple of 8:

Code:
102402090 +         0 = 102402090 : not aligned
102402090 +   2097152 = 104499242 : not aligned
102402090 +  65011712 = 167413802 : not aligned
102402090 + 127926272 = 230328362 : not aligned
102402090 + 136314880 = 238716970 : not aligned

After a full backup, those FreeBSD partitions can be deleted and recreated with gpart(8) using the -a4K option. The starting block will be adjusted so it is aligned.
 
Back
Top