Problem with SSD, copying files, filesystem?

Hi,

recently I have discovered some potential problematic issues with my Leap 15 installation. It’s installed on a new Crucial MX500 SSD using the preset BTRFS+XFS configuration.
First I noticed that sometimes copying files to an external SSD/pen drive would become very slow after a while. It starts off at normal speed, but drops to very slow to zero after it’s half through.
Sometimes I get an error message in Dolphin:

Could not write to run/media/.../file.pdf

If I skip the message would pop up shortly after once again.

When I try rebooting the system it takes ages for it to shut down and I get a whole bunch of error messages, that my /home, /var, /… was not successfully unmounted. The start up takes a while as well but after coming back all seems to be working fine again…
Journalctl gives me some messages:

Jun 13 23:16:13 PC kernel: ACPI Error: _SB_.PCI0.XHC_.RHUB.SSP3] Namespace lookup failure, AE_NOT_FOUND (20170303/dswload-210)
Jun 13 23:16:13 PC kernel: ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20170303/psobject-241)
Jun 13 23:16:13 PC kernel: ACPI Exception: AE_NOT_FOUND, (SSDT:DockSsdt) while loading table (20170303/tbxfload-228)
Jun 13 23:16:13 PC kernel: ACPI Error: 1 table load failures, 7 successful (20170303/tbxfload-246)
Jun 13 23:16:16 PC kernel: FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

The ACPI Error:1 I get during every boot. But I’m more worried about the FAT-fs message.

So is my pen drive broken? Is my SSD broken or is it a filesystem problem with my OpenSuse installation?
Either way, help would be much appreciated :slight_smile:

Thanks.

On Sat 16 Jun 2018 09:36:03 AM CDT, SF6 wrote:

Hi,

recently I have discovered some potential problematic issues with my
Leap 15 installation. It’s installed on a new Crucial MX500 SSD using
the preset BTRFS+XFS configuration.
First I noticed that sometimes copying files to an external SSD/pen
drive would become very slow after a while. It starts off at normal
speed, but drops to very slow to zero after it’s half through.
Sometimes I get an error message in Dolphin:

Code:

Could not write to run/media/…/file.pdf

If I skip the message would pop up shortly after once again.

When I try rebooting the system it takes ages for it to shut down and I
get a whole bunch of error messages, that my /home, /var, /… was not
successfully unmounted. The start up takes a while as well but after
coming back all seems to be working fine again…
Journalctl gives me some messages:

> Jun 13 23:16:13 PC kernel: ACPI Error: _SB_.PCI0.XHC_.RHUB.SSP3]
> Namespace lookup failure, AE_NOT_FOUND (20170303/dswload-210)

> Jun 13 23:16:13 PC kernel: ACPI Exception: AE_NOT_FOUND, During name
> lookup/catalog (20170303/psobject-241)

> Jun 13 23:16:13 PC kernel: ACPI Exception: AE_NOT_FOUND,
> (SSDT:DockSsdt) while loading table (20170303/tbxfload-228)

> Jun 13 23:16:13 PC kernel: ACPI Error: 1 table load failures, 7
> successful (20170303/tbxfload-246)

> Jun 13 23:16:16 PC kernel: FAT-fs (sda1): Volume was not properly
> unmounted. Some data may be corrupt. Please run fsck.

>
>

The ACPI Error:1 I get during every boot. But I’m more worried about the
FAT-fs message.

So is my pen drive broken? Is my SSD broken or is it a filesystem
problem with my OpenSuse installation?
Either way, help would be much appreciated :slight_smile:

Thanks.

Hi
So with USB storage devices, things may still be writing even after you
unmount via a GUI… you should either wait for a notification, or if a
USB device with LED until it stops flashing. This is a bit hard with
things like SD cards, so I always run the command sync from the
command line and wait till it finishes, then repeat just to be sure.

They are just slow writing sometimes so the cache needs to flush to the
device. This could be your issue and has probably just set the dirty
bit flag which can be fixed as per the log command fsck…

Open a terminal session, plug in the device in question and switch to
root user;


su -
umount /dev/sdX
sync
fsck /dev/sdX
sync

Where X is your device name eg sdc, fsck will sort out the filesystem
type and you will probably be notified about the dirty bit and can
clear it.

ACPI errors (system DSDT), updating BIOS may help, else consider a bug
report, but may not get fixed… sometimes setting the acpi_osi=“Linux”
and permutations of (eg “!Windows2012”) it on the kernel command line
options may help, a google will show acpi options.

Old Ref: ftp://ftp.suse.com/pub/people/trenn/ACPI_BIOS_on_Linux_guide/acpi_guideline_for_vendors.pdf


Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-23-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!