Hello, I am wondering if this drive is failing. I ran a GSmartControl - extended test and no errors were detected that way. Noticing here on this machine with some of the journalctl -xb output shown in the following lines: Feb 02 17:10:09 Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=524288, sector=32768, nr_sectors = 8 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32768, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 0, async page read Feb 02 17:10:09 Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32769, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 1, async page read Feb 02 17:10:09 Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32770, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 2, async page read Feb 02 17:10:09 Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32771, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 3, async page read Feb 02 17:10:09 paul-Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32772, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 4, async page read Feb 02 17:10:09 paul-Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32773, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 5, async page read Feb 02 17:10:09 Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32774, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 6, async page read Feb 02 17:10:09 paul-Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32775, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 7, async page read Feb 02 17:10:09 Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32768, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 0, async page read Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 1, async page read There is no /dev/sdb device showing up in fdisk -l or lsblk -fs right now though so could it be an iteration of the past when possibly my (usb filing drive) was connected to the machine? Also I would like to ask you about all this information about COW and Btrfs. What's going on here with 'defragmenting' and 'scrubbing' in a generalized sense? What is a sign of the need for it? I've been experiencing a minor freeze for about 45 seconds to a minute after a powercycle and login but then things seem to clear up.
On 03.02.2024 08:21, -pj via openSUSE Users wrote:
Hello, I am wondering if this drive is failing. I ran a GSmartControl - extended test and no errors were detected that way. Noticing here on this machine with some of the journalctl -xb output shown in the following lines:
Feb 02 17:10:09 Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=524288, sector=32768, nr_sectors = 8 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32768, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 0, async page read Feb 02 17:10:09 Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32769, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 1, async page read Feb 02 17:10:09 Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32770, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 2, async page read Feb 02 17:10:09 Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32771, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 3, async page read Feb 02 17:10:09 paul-Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32772, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 4, async page read Feb 02 17:10:09 paul-Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32773, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 5, async page read Feb 02 17:10:09 Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32774, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 6, async page read Feb 02 17:10:09 paul-Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32775, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 7, async page read Feb 02 17:10:09 Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=0, sector=32768, nr_sectors = 1 limit=0 Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 0, async page read Feb 02 17:10:09 Thinkcentre-M57p kernel: Buffer I/O error on dev dm-3, logical block 1, async page read
There is no /dev/sdb device showing up in fdisk -l or lsblk -fs right now though so could it be an iteration of the past when possibly my (usb filing drive) was connected to the machine?
Show ls -l /sys/block
Also I would like to ask you about all this information about COW and Btrfs. What's going on here with 'defragmenting' and 'scrubbing' in a generalized sense? What is a sign of the need for it? I've been experiencing a minor freeze for about 45 seconds to a minute after a powercycle and login but then things seem to clear up.
Thinkcentre-M57p:/usr/share/susepaste> ls -l /sys/block total 0 lrwxrwxrwx 1 root root 0 Feb 2 16:33 dm-0 -> ../devices/virtual/block/dm-0 lrwxrwxrwx 1 root root 0 Feb 2 17:10 dm-1 -> ../devices/virtual/block/dm-1 lrwxrwxrwx 1 root root 0 Feb 2 17:10 dm-2 -> ../devices/virtual/block/dm-2 lrwxrwxrwx 1 root root 0 Feb 2 17:19 dm-3 -> ../devices/virtual/block/dm-3 lrwxrwxrwx 1 root root 0 Feb 2 16:33 fd0 -> ../devices/platform/floppy.0/block/fd0 lrwxrwxrwx 1 root root 0 Feb 2 17:10 sda -> ../devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda lrwxrwxrwx 1 root root 0 Feb 2 17:16 sdc -> ../devices/pci0000:00/0000:00:1d.7/usb3/3-6/3-6:1.0/host5/target5:0:0/5:0:0:0/block/sdc lrwxrwxrwx 1 root root 0 Feb 2 16:33 sr0 -> ../devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0 Thinkcentre-M57p:/usr/share/susepaste>
On 02-03-2024 12:07AM, Andrei Borzenkov wrote:
ls -l /sys/block
On 03.02.2024 09:13, -pj via openSUSE Users wrote:
Thinkcentre-M57p:/usr/share/susepaste> ls -l /sys/block total 0 lrwxrwxrwx 1 root root 0 Feb 2 16:33 dm-0 -> ../devices/virtual/block/dm-0 lrwxrwxrwx 1 root root 0 Feb 2 17:10 dm-1 -> ../devices/virtual/block/dm-1 lrwxrwxrwx 1 root root 0 Feb 2 17:10 dm-2 -> ../devices/virtual/block/dm-2 lrwxrwxrwx 1 root root 0 Feb 2 17:19 dm-3 -> ../devices/virtual/block/dm-3 lrwxrwxrwx 1 root root 0 Feb 2 16:33 fd0 -> ../devices/platform/floppy.0/block/fd0 lrwxrwxrwx 1 root root 0 Feb 2 17:10 sda -> ../devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda lrwxrwxrwx 1 root root 0 Feb 2 17:16 sdc -> ../devices/pci0000:00/0000:00:1d.7/usb3/3-6/3-6:1.0/host5/target5:0:0/5:0:0:0/block/sdc lrwxrwxrwx 1 root root 0 Feb 2 16:33 sr0 -> ../devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0 Thinkcentre-M57p:/usr/share/susepaste>
On 02-03-2024 12:07AM, Andrei Borzenkov wrote:
ls -l /sys/block
OK, so messages are apparently 7 hours old and refer to the device that is no more present on your system. Nothing can be guessed about them now. You can run "journalctl -b" and investigate when sdb appeared and disappeared. But messages themselves are not direct indications of any hardware failure. They may be consequences of hardware failure, but for this you need to look in logs for earlier errors.
On 2024-02-03 06:21, -pj via openSUSE Users wrote:
Hello, I am wondering if this drive is failing. I ran a GSmartControl - extended test and no errors were detected that way. Noticing here on this machine with some of the journalctl -xb output shown in the following lines:
Feb 02 17:10:09 Thinkcentre-M57p kernel: fdisk: attempt to access beyond end of device sdb: rw=524288, sector=32768, nr_sectors = 8 limit=0
...
There is no /dev/sdb device showing up in fdisk -l or lsblk -fs right now though so could it be an iteration of the past when possibly my (usb filing drive) was connected to the machine?
This is an error that happened when /dev/sdb was connected. Taking a guess, the size of the disk changed to "zero", so access failed. This may happen when removing an USB disk without telling the system.
Also I would like to ask you about all this information about COW and Btrfs. What's going on here with 'defragmenting' and 'scrubbing' in a generalized sense? What is a sign of the need for it? I've been experiencing a minor freeze for about 45 seconds to a minute after a powercycle and login but then things seem to clear up.
Huh, one question at a time, my single waken up neuron has gone paff! -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
participants (3)
-
-pj -
Andrei Borzenkov -
Carlos E. R.