I recently performed a clean install of Fedora 37
on to a 1TB SSD drive. I used a GPT partition table.

I have four data partitions, each 200G, named
/u1, /u2, /u3, /u4, all with Ext4.

After the initial install I booted up without problem.

Then, when I restored data to these partitions and rebooted.
I was put into emergency mode and found that I had errors
on partition /u3 (sda7)

When I removed /u3 (sda7) from /etc/fstab and booted,
the machine booted up without problem.

So, I deleted the /u3 (sda7) partition with GParted,
added it again and reformatted it.

When I loaded data on to the (sda7) partition AGAIN,
things went fine but when I test rebooted AGAIN,
the /u3 (sda7) partition still forced me into
emergency mode, because of EXT4-fs errors on this
partition.

---

What more can I do to fix this partition?

Is this SSD drive permanently damaged?
Is is less than two years old.

Might changing the file system of this
partition to btrfs make a difference?

Thank you for your help.

It very well could be that the section of SSD where sda7 lives has bad spot or spots. Use smartctl -t long /dev/sda7 to test it, smartctl -x /dev/sda7 | less to evaluate the results after the long test completes. Before deleting the partition the first time you should have run a forced fsck on it. If you have any other disk you could use you could put a similar partition on it to restore u3's data to do be sure the data from your backup isn't causing a problem. Can you create new data on a freshly formatted sda7 without experiencing errors? The filesystem type is unlikely to play a role in this. SSDs are like any new electro-mechanical technology, subject to failure for random reasons. I've had 4-5 complete SSD failures out of about 20 SSDs of about a dozen brands in less than 5 years. I'm not thrilled about the SSD track record I've experienced.

1 members found this post helpful.

I would try turning off lazyinit and see if the error still occurs. This will extend the mkfs time - noticably for a large partition.

First, check the image file of the suspect partition by mounting it as loop device. Disk failing this way is unlikely, but check its SMART and logs for disk-related error messages. Also, partprobe will re-read partitions without rebooting.

mrmazda wrote:
And that was the ticket. When I ran fsck on /dev/sda7,
numerous errors were corrected.


Then, when I loaded data onto /u3 again, there were no more errors
and the machine has booted up fine several times now.


I suspect that when I deleted and then re-added the /u3 partition
with GParted the first time, Gparted did not actually reformat
the partition, as I had thought.

Thank you all for your help.

Concerning fsck: rather than wait until a partition has a problem,
is fsck something that people run regularly on partitions,
just for regular maintenance?

Whether and when an admin should run a manual fsck is generally a judgement call. An admin can perform a fsck at any time desired, as long as the filesystem can be unmounted. As in your case, it can become mandatory as prerequisite to mounting and thus data access. On extX filesystem creation, a time interval and mount counts are configured in and for that filesystem. After the earliest test to occur, mounting is disallowed until fsck is performed. These limits are customizable with tune2fs to as little as never by time (-i0) and zero mounts (-c0). Each line in fstab designates whether and when a fsck may be performed automatically during the init process via the last column's value (0=not, 1=first, 2=after first).
man fstab
man mke2fs
man tune2fs
Other checking rules apply to other filesystem types.

1 members found this post helpful.