Gnome takes MORE THAN 20 SECONDS to open a folder

[Glen Byram]

After upgrading from 18.04 to 20.04, Ubuntu has become UNUSABLE. When I try to open e.g. my home folder, or "New Window" from the file tool in the app bar, it can take 15, 20 or 30 seconds for anything to happen. Then sometimes the response is instant. Something is seriously seriously wrong with your software.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: gnome-shell 3.36.4-1ubuntu1~20.04.2
ProcVersionSignature: Ubuntu 5.4.0-51.56-generic 5.4.65
Uname: Linux 5.4.0-51-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.9
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Wed Oct 14 13:31:10 2020
DisplayManager: gdm3
InstallationDate: Installed on 2017-05-31 (1231 days ago)
InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2)
RelatedPackageVersions: mutter-common 3.36.6-1ubuntu0.20.04.2
SourcePackage: gnome-shell
UpgradeStatus: No upgrade log present (probably fresh install)

[Daniel van Vugt (vanvugt)]

It sounds like nautilus is blocked waiting for one or more slow mounts. Most likely that's a network mount, so try removing any of those temporarily. Less likely it's a local disk failure.

Please also check that the problem is not high CPU by running 'top'.

If you can't find the source of the problem then please:

 1. Reboot to create a fresh system log.

 2. Reproduce the problem once.

 3. Immediately run:

    journalctl -b0 > journal.txt

    and attach the resulting text file here.

[Glen Byram (glen.byram.666)]

On 10/14/20 1:54 PM, Daniel van Vugt wrote:
> journalctl -b0 > journal.txt

--
Glen Byram
<email address hidden>

[Daniel van Vugt (vanvugt)]

Thanks. It appears your sda harddisk (Seagate 500GB) is failing with hardware errors. I suggest the best, perhaps only, solution is to replace the harddisk. At least that's the first thing I would do before assuming this is a software problem...

Oct 23 19:10:22 g-linux kernel: ata1.00: exception Emask 0x0 SAct 0x7803 SErr 0x0 action 0x0
Oct 23 19:10:22 g-linux kernel: ata1.00: irq_stat 0x40000008
Oct 23 19:10:22 g-linux kernel: ata1.00: failed command: READ FPDMA QUEUED
Oct 23 19:10:22 g-linux kernel: ata1.00: cmd 60/08:58:b8:a9:0a/00:00:37:00:00/40 tag 11 ncq dma 4096 in
                                         res 41/40:08:b8:a9:0a/00:00:37:00:00/00 Emask 0x409 (media error) <F>
Oct 23 19:10:22 g-linux kernel: ata1.00: status: { DRDY ERR }
Oct 23 19:10:22 g-linux kernel: ata1.00: error: { UNC }
Oct 23 19:10:22 g-linux kernel: ata1.00: configured for UDMA/133
Oct 23 19:10:22 g-linux kernel: sd 0:0:0:0: [sda] tag#11 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Oct 23 19:10:22 g-linux kernel: sd 0:0:0:0: [sda] tag#11 Sense Key : Medium Error [current]
Oct 23 19:10:22 g-linux kernel: sd 0:0:0:0: [sda] tag#11 Add. Sense: Unrecovered read error - auto reallocate failed
Oct 23 19:10:22 g-linux kernel: sd 0:0:0:0: [sda] tag#11 CDB: Read(10) 28 00 37 0a a9 b8 00 00 08 00
Oct 23 19:10:22 g-linux kernel: blk_update_request: I/O error, dev sda, sector 923445688 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Oct 23 19:10:22 g-linux kernel: ata1: EH complete

[Glen Byram (glen.byram.666)]

Thanks for your speedy reply. However I disagree with your diagnosis.

The problem I reported seems to have been fixed by a series of updates,
that I downloaded shortly after sending you the log. So a software patch
seems to have made the problem vanish,

Whatever problems my harddisk has did not have ANY impact on browsing
files in 18.04. As I reported initially, the problem started ONLY and
IMMEDIATELY after the initial 20.04 upgrade.

I therefore looked at the immediate PRECIPITATING CAUSE of the problem,
version upgrade, before assuming it is a hardware problem.

Anyway, thanks again for your time.

On 10/23/20 8:35 PM, Daniel van Vugt wrote:
> Thanks. It appears your sda harddisk (Seagate 500GB) is failing with
> hardware errors. I suggest the best, perhaps only, solution is to
> replace the harddisk. At least that's the first thing I would do before
> assuming this is a software problem...
>
>
> Oct 23 19:10:22 g-linux kernel: ata1.00: exception Emask 0x0 SAct 0x7803 SErr 0x0 action 0x0
> Oct 23 19:10:22 g-linux kernel: ata1.00: irq_stat 0x40000008
> Oct 23 19:10:22 g-linux kernel: ata1.00: failed command: READ FPDMA QUEUED
> Oct 23 19:10:22 g-linux kernel: ata1.00: cmd 60/08:58:b8:a9:0a/00:00:37:00:00/40 tag 11 ncq dma 4096 in
> res 41/40:08:b8:a9:0a/00:00:37:00:00/00 Emask 0x409 (media error) <F>
> Oct 23 19:10:22 g-linux kernel: ata1.00: status: { DRDY ERR }
> Oct 23 19:10:22 g-linux kernel: ata1.00: error: { UNC }
> Oct 23 19:10:22 g-linux kernel: ata1.00: configured for UDMA/133
> Oct 23 19:10:22 g-linux kernel: sd 0:0:0:0: [sda] tag#11 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> Oct 23 19:10:22 g-linux kernel: sd 0:0:0:0: [sda] tag#11 Sense Key : Medium Error [current]
> Oct 23 19:10:22 g-linux kernel: sd 0:0:0:0: [sda] tag#11 Add. Sense: Unrecovered read error - auto reallocate failed
> Oct 23 19:10:22 g-linux kernel: sd 0:0:0:0: [sda] tag#11 CDB: Read(10) 28 00 37 0a a9 b8 00 00 08 00
> Oct 23 19:10:22 g-linux kernel: blk_update_request: I/O error, dev sda, sector 923445688 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
> Oct 23 19:10:22 g-linux kernel: ata1: EH complete
>
--
Glen Byram
<email address hidden>

[Sebastien Bacher (seb128)]

thanks, closing since that has been fixed in an update