# Slow I/O on Laptop



## ORTO-DOX (Jun 20, 2013)

Hi *a*ll!

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 try_ing_ to extract _a_ ports snapshot in Windows).

And when I see `gstat` on that moment:

```
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`

```
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
```


----------



## SirDice (Jun 20, 2013)

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.


----------



## DutchDaemon (Jun 20, 2013)

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 (Jun 20, 2013)

@ORTO-DOX

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


----------



## ORTO-DOX (Jun 20, 2013)

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


----------



## t1066 (Jun 21, 2013)

`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.


----------



## ORTO-DOX (Jun 21, 2013)

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.


----------



## Crivens (Jun 21, 2013)

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.


----------



## HarryE (Jun 21, 2013)

I've seen a Dell laptop behaving the same way having Windozews on it. The problem was some _S_outhbridge design flaw. The default driver was not aware of that. Google it.


----------



## G_Nerc (Jun 21, 2013)

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?


----------



## t1066 (Jun 22, 2013)

It seems that the hard drive is using '4K advance format'. Are the partitions aligned correctly?


----------



## G_Nerc (Jun 22, 2013)

t1066 said:
			
		

> It seems that the hard drive is using '4K advance format'. Are the partitions aligned correctly?



How can I check whether partitions are aligned or not?


----------



## wblock@ (Jun 22, 2013)

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.


----------



## G_Nerc (Jun 23, 2013)

```
=>       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*.*


----------



## wblock@ (Jun 23, 2013)

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.


----------



## ORTO-DOX (Jun 24, 2013)

@wblock@ and @t1066 thank you for digging into _my_ problem  Can I resolve my problem somehow without reinstall_ing the_ system?


----------



## wblock@ (Jun 24, 2013)

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`.


----------



## jem (Jun 24, 2013)

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.


----------



## wblock@ (Jun 24, 2013)

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.


----------



## ORTO-DOX (Jun 25, 2013)

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`

```
=>        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)
```


----------



## wblock@ (Jun 25, 2013)

ORTO-DOX said:
			
		

> `gpart show ada0`
> 
> ```
> =>       63  976773105  ada0  MBR  (465G)
> ...



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:


```
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.


----------



## G_Nerc (Jun 25, 2013)

Thanks @wblock@ for an absolutely complete answer  I will write here about the results!


----------

