this post was submitted on 13 Oct 2023
31 points (83.0% liked)
Linux
48072 readers
1 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 6 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Attempt to read block from filesystem resulted in short read while trying to open /dev/sdd1 Could this be a zero-length partition?
fsck is probably wrong in guessing that it's a zero-length partition; I would be more-inclined to guess that a read error caused it not to be able to read anything.
That should display the partition table on the drive, as well as the lengths of the partition. My guess is that it'll just show that you have a 4.5TB partition. Probably starts at something like 1MB and ends at something like 4500GB.
Linux was able to read from the drive enough to get at the partition table on it, or the
lsblkoutput you had above in that image wouldn't be able to show the partition.But I'd guess that it's hitting read errors in trying to read from the drive, and that the way that this is percolating up to fsck is fsck asking for N bytes and getting back only the bytes that it could read before it hit the error.
It's maybe not impossible that an invalid partition table could produce that error. And maybe e2fsck is trying to read off the end of the device or something because the filesystem on the partition is messed up, but I'm biased towards to thinking that it's more-likely that the drive is failing.
The first option I'm normally going to take when maybe a hard drive is dying is:
As long as the drive supports SMART, that'll tell you whether the drive thinks that it's failing. That won't catch everything, but if the drive doesn't give itself a clean bill of health, then I wouldn't either.
If the kernel is trying to read data from a drive and seeing errors, it'll probably show up in the kernel log.
Should show you errors in the kernel log from the current boot relating to that drive.
If you don't see any errors there, then I'd be inclined to see whether it's possible to read the contents of the partition and whether that can do so. Something like -- and be very careful not to reverse the "if" (input file) and "of" (output file) parameters here, because
ddcan write to a drive and if typed incorrectly, this can overwrite your drive's contents:That'll just try reading from the beginning of the partition, giving you updates as it goes to let you know how much it's read, and then just dump the data into /dev/null. If it fails to read data at some point, it should bail out way before 4.5TB. Probably don't want to wait for the whole partition to be read, though, because 4.5TB is gonna take a while.
If dd can read the contents of the partition, then I assume that e2fsck should be able to as well.
If dd can read the data, then I'd assume that something is wrong with the filesystem, or at least the data on the partition, and it'd make sense to look at that.
If dd can't read the data, then I'd be inclined to blame hardware (or maybe the partition table), since nothing inside the partition itself, including the filesystem, should be able to make dd fail to read the contents of the partition; dd doesn't actually pay any attention to the data that it's reading.
The commands were fine but dd.
Input/output error means the drive is just dying, irrespective of the software. Software can't do anything about failing hardware, and that's what you ran into.
Probably so, but just to be certain about the partition table not causing it, I'd maybe try running the
ddcommand on /dev/sdd rather than /dev/sdd1. It should be able to read a little more than the attempt to read /dev/sdd1 did. I'm not absolutely certain what happens if a partition table is invalid and has a partition that includes a region extending off the end of the hard drive, and I haven't actually seen a dump of the partition table posted by OP. It might be that an attempt to read a partition that extends off the end of the drive gets exposed to an application as an I/O error.I'm also a little surprised by the lack of kernel log messages. Maybe things have changed, but with all of IDE and SATA internal drives, I always got errors logged with the kernel if I/O failed on a drive, and they always referenced the drive's device name.
I just can't think of much higher level stuff that would cause I/O errors while trying to read at a partition level, though.
And a failing drive could also explain the freeze in Arch, the slow booting of Debian, the inability to mount the drive, and the I/O errors, so it'd explain a lot.