That’s why I said “if” and recommended to do the alignment-check. That will tell you.
@jimoe666 and others:
Actually, it didn’t occur to me when I was typing in my previous answer here, but the rounding error is demonstrated in my dump from my test computer. My first partition is listed to start at 1049kB, which isn’t any factor of 512B, yet it is properly aligned as is demonstrated in the example (I also know I aligned the first partition to 1MiB).
That fact renders parted’s print partition output only to be approximately correct, and nothing to base any technical decision upon. Also, - and this is speculation - parted’s unit usage may have changed between version 2.4 and 3.1, and the latter version is the basis for my reasoning (as I said). I don’t know. v3.1 is listed to use kiB just as well as kB. When 1024kiB is accurate (which spells out to 1048.576kB BTW), why use a rounded and inaccurate 1049kB in its place? That could mean v2.4 doesn’t use kiB/MiB/GiB at all, but it still is true to the use of kB/MB/GB. The output, however, isn’t really useful.
Nonetheless, parted’s alignment-check will tell you - as it does in this case:
The minimum alignment is in place (512B I presume, and it confirms the inaccuracy of parted’s print partition output). The optimal alignment isn’t in place. What parted think is optimal alignment, I don’t know. I am not familiar enough yet with Linux disk handling to tell, but it normally has to do with caching and prefetching data optimally. Getting that right, will improve your disk performance. As a “qualified guess” I would, however, expect 1MiB to hit the optimal value for you as well (=the optimal value being something that will multiply by itself or an even factor into 1MiB), as most partitioning tools these days use that as a default alignment value.
Now, what remains is to find out why it is so slow - at least when reading partition tables. How is the speed of the disk in normal use, BTW?
Some more speculation - and something to try (based on my own experience):
It may even be that the magnetic layer on the platters are weak, and starts to loose its “signal”. Historically, static info on magnetic disks used to fade out after a while. In the early days, after 2 years of data storage without (re)writing, it wasn’t uncommon to loose data. I’ve “repaired” several harddisks over the years by rewriting its contents. There even was a SW-tool, SpinRite, that automated these things while at the same time being able to pick up info that normally couldn’t be read - which in fact made it a SW-harddisk-technician in its own right. I had even more success using that tool. Then harddisk controllers changed and rendered SpinRite useless. It was back to data rewriting only. Harddisks improved also, so data refreshing is less necessary these days, but it is no doubt still useful for a disk of the right state.
The other partition-reading utilities may have timed out while waiting for proper results to arrive, and parted may have just that tad longer timeout to be able to read it.
I recommend that you execute the disk-test suggested by ratzi.
If it turn out ok, the next thing would be to try rewriting the partition table (=refresh the magnetic media where the partition table is physically written). If that proves to remedy your problem (rewriting the partition table alone doesn’t take much time, and it doesn’t need much space elsewhere, either), then it may be an idea to refresh the whole disk as you may have other spots on the platters that are very rarely used. Those spots would gain from a magnetic refresh too.
You can use “dd” for that, but I am not fluent enough with that tool yet to dare to recommend any syntax for it now. Maybe someone could suggest a current tool that does it automatically, while being aimed at the end user (I doubt I am the only one that have had this experience). Using “dd” would be a two-step process, where the first part would be to read the data FROM the disk (and store it elsewhere), and the second part would be to write these data back in the original spots.
If you decide that partition re-alignment is of interest, you should be prepared for such a tool to be data destructive, but I really don’t know if they are. You should search for “partition re-alignment” on the internet, and pick the tool that fits you the most. I have never used any of those, as I would normally simply flush the disk completely and rebuild it from the ground up - including new partition tables - using original installation media as much as I can, and filling in with data restore where original install is insufficient. Such a process also counts for rewriting the parts of the disk that are rarely written to, and render the data-rewriting principle superfluous. In fact, I’ve done that often enough the later years, that I haven’t been using the data rewrite principle since disks were <<2GiB in size, and I never rewrote/updated that utility.
Again: Due to today’s improved disk technology (which I beleive also includes OP’s “old” disk), rewriting the partition table may be speculative. Nevertheless, considering the time it would take, it could prove to be worth-while. If it proves otherwise, it didn’t take much of your time.
Maybe someone in this forum can help you with the right dd-command parametres to carry out that task, if you don’t know how to do it already.
dayfinger