HDD problems or something else?

OK, ran the second version of your script. This time, it was interesting, in that suddenly dtrace decided to stop displaying messages - without me doing anything other than stare at screen - and the extraction of the package continued but the debug messages were no longer displayed so I decided to stop the entire process since it seemed pointless to continue without those messages.

The forum did not allow me to enter the entire body of the report, even within spoiler tags, so I saved it as a compressed file and attached it.
 

Attachments

  • messages.txt.zip
    3 KB · Views: 82
This bug seems similar to what I'm experiencing but then why does this problem disappear after replacing the HDD on the main system?
 
No, but I should clarify: this problem first appeared on my main system (the FX 8350 based system) with 4 HDDs installed into it, one of them being a Toshiba drive with FreeBSD installed on it.
Because I was frustrated with this whole situation, I have replaced the Toshiba drive with a Hitachi one and reinstalled FreeBSD on that new disk and this problem no longer appears after that - the install times are much more reasonable now on my main system, I have posted a time report.


But I have another system, a HP with a 250 GB HDD which also had FreeBSD on it and on that configuration pkg's install times were also normal, not slow (tested it too).
Well, I replaced that 250 GB HDD with the Toshiba drive that was taken out of the main system, reinstalled FreeBSD on it and the problem with pkg appeared again. Then I decided to continue testing but this time on the HP.
So, all of your tests were done on that HP with that Toshiba since it seems that this drive is good, not defective and yet pkg behaves the way it did on the main system.

Is it more clear now?
 
This bug seems similar to what I'm experiencing but then why does this problem disappear after replacing the HDD on the main system?
That bug is only triggered when journaled softupdates is enabled on a UFS filesystem. Is that the case for your Toshiba disk? If so, please disable journaling for that file system, i.e. run tunefs -j disable /dev/whatever while the file system is not mounted (or mounted read-only), see the tunefs(8) manual page for details. Then check if the problem persists.
 
olli@: did as you suggested, disabled journaling ( tunefs -j disable /dev/ada0s1a) on that Toshiba drive but still no change, still slow extracting with pkg.

But, just for the heck of it, I decided to reinstall FreeBSD on the HP with the Toshiba drive but this time with ZFS as the file system.
And, lo and behold, much better install times:

Code:
# time pkg install flat-remix-icon-themes
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
    flat-remix-icon-themes: 20201112

Number of packages to be installed: 1

The process will require 273 MiB more space.
38 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching flat-remix-icon-themes-20201112.txz:   5%    2 MiB   2.0MB/s    0[1/1] Fetching flat-remix-icon-themes-20201112.txz:  12%    5 MiB   2.9MB/s    0[1/1] Fetching flat-remix-icon-themes-20201112.txz:  19%    8 MiB   3.0MB/s    0[1/1] Fetching flat-remix-icon-themes-20201112.txz:  27%   10 MiB   3.0MB/s    0[1/1] Fetching flat-remix-icon-themes-20201112.txz:  34%   13 MiB   3.0MB/s    0[1/1] Fetching flat-remix-icon-themes-20201112.txz:  42%   16 MiB   3.0MB/s    0[1/1] Fetching flat-remix-icon-themes-20201112.txz:  49%   19 MiB   3.0MB/s    0[1/1] Fetching flat-remix-icon-themes-20201112.txz:  57%   22 MiB   3.0MB/s    0[1/1] Fetching flat-remix-icon-themes-20201112.txz:  64%   25 MiB   3.0MB/s    0[1/1] Fetching flat-remix-icon-themes-20201112.txz:  72%   28 MiB   3.0MB/s    0[1/1] Fetching flat-remix-icon-themes-20201112.txz:  79%   31 MiB   3.0MB/s    0[1/1] Fetching flat-remix-icon-themes-20201112.txz:  87%   33 MiB   3.1MB/s    0[1/1] Fetching flat-remix-icon-themes-20201112.txz:  94%   36 MiB   3.0MB/s    0[1/1] Fetching flat-remix-icon-themes-20201112.txz: 100%   38 MiB   3.1MB/s    00:13   
Checking integrity... done (0 conflicting)
[1/1] Installing flat-remix-icon-themes-20201112...
[1/1] Extracting flat-remix-icon-themes-20201112: 100%
19.065u 40.813s 1:16.03 78.7%    2651+29060k 159353+81538io 15pf+0w
Although with a lot higher CPU usage, if I understand it correctly.

It seems it's indeed a bug involving pkg and UFS but why does this bug not manifest on the Hitachi drive in the main system which also has FreeBSD with UFS? It's possible that this bug (if it's a bug) only triggers on some brands/models of drives?

It's really weird.
 
It seems it's indeed a bug involving pkg and UFS but why does this bug not manifest on the Hitachi drive in the main system which also has FreeBSD with UFS? It's possible that this bug (if it's a bug) only triggers on some brands/models of drives?
Well, different drives may behave differently, regarding the behavior of write-back caches, ordering of queued tags (when NCQ is supported) and other details in the firmware. Even if drives have the same size of cache, the firmware can manage it in different ways.
 
olli@: I think you're right. Would FreeBSD 12.2 be better (i.e without this problem)? I haven't upgraded to it yet because of the bug with drm-kmod.

facedebouc: yes, soft-updates were enabled on the Toshiba drive (they're enabled by default) but I have disabled journaling as per olli@'s advice and no change, the problem was still present. Now I have ZFS on that drive and, as I showed above, the problem no longer appears.
 
olli@: I think you're right. Would FreeBSD 12.2 be better (i.e without this problem)? I haven't upgraded to it yet because of the bug with drm-kmod.
Difficult to to tell … If the performance problem is caused by a firmware issue that is triggered by UFS, then an upgrade won’t change it, I’m afraid. By the way, I wouldn’t call it a “bug”; maybe it is just an unfortunate interaction between the drive firmware and the UFS code.

ZFS works very different from UFS. It is a COW file system (copy-on-write) and handles write-barriers and tags differently from UFS, which means that it also uses the drive’s cache differently. So maybe it doesn’t trigger the firmware issue, and that’s why this particular problem is mitigated when you switch to ZFS.

All of that is just speculation, of course, but it doesn’t sound unlikely.
 
Back
Top