Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #275226 > unrolled thread

ext4 FS Crash

Back to article view | Back to linux.debian.user

Contents

  ext4 FS Crash Daniel Harris <mail.dharris@googlemail.com> - 2024-12-04 13:30 +0100
    Re: ext4 FS Crash Jochen Spieker <ml@well-adjusted.de> - 2024-12-04 13:50 +0100
    Re: ext4 FS Crash Eike Lantzsch ZP5CGE / KY4PZ <zp6cge@gmx.net> - 2024-12-04 15:40 +0100
      Re: ext4 FS Crash "Andrew M.A. Cater" <amacater@einval.com> - 2024-12-04 19:20 +0100
    Re: ext4 FS Crash "Alexander V. Makartsev" <avbetev@gmail.com> - 2024-12-04 17:30 +0100
    Re: ext4 FS Crash Klaus Singvogel <deb-user-ml@singvogel.net> - 2024-12-04 17:50 +0100
      Re: ext4 FS Crash Daniel Harris <mail.dharris@googlemail.com> - 2024-12-04 18:20 +0100
        Re: ext4 FS Crash Michael Stone <mstone@debian.org> - 2024-12-05 00:50 +0100
          Re: ext4 FS Crash Daniel Harris <mail.dharris@googlemail.com> - 2024-12-05 12:00 +0100
            Re: ext4 FS Crash Michael Stone <mstone@debian.org> - 2024-12-05 13:40 +0100
              Re: ext4 FS Crash Daniel Harris <mail.dharris@googlemail.com> - 2024-12-05 16:40 +0100
        Re: ext4 FS Crash Jörg-Volker Peetz <jvpeetz@web.de> - 2024-12-05 10:30 +0100
          Re: ext4 FS Crash Max Nikulin <manikulin@gmail.com> - 2024-12-05 16:30 +0100
            Re: ext4 FS Crash Erwan David <erwan@rail.eu.org> - 2024-12-05 16:40 +0100
              Re: ext4 FS Crash Andy Smith <andy@strugglers.net> - 2024-12-05 17:10 +0100
              Re: ext4 FS Crash gene heskett <gheskett@shentel.net> - 2024-12-06 02:00 +0100
            Re: ext4 FS Crash Michael Stone <mstone@debian.org> - 2024-12-05 18:50 +0100
              Re: ext4 FS Crash Jörg-Volker Peetz <jvpeetz@web.de> - 2024-12-06 14:30 +0100
                Re: ext4 FS Crash Michael Stone <mstone@debian.org> - 2024-12-06 15:00 +0100
                  Re: ext4 FS Crash Jörg-Volker Peetz <jvpeetz@web.de> - 2024-12-06 15:10 +0100
                    Re: ext4 FS Crash Max Nikulin <manikulin@gmail.com> - 2024-12-06 17:00 +0100
                      Re: ext4 FS Crash Michael Stone <mstone@debian.org> - 2024-12-06 17:40 +0100
                        Re: ext4 FS Crash Max Nikulin <manikulin@gmail.com> - 2024-12-08 17:30 +0100
                          Re: ext4 FS Crash Michael Stone <mstone@debian.org> - 2024-12-08 18:20 +0100
                            Re: ext4 FS Crash Max Nikulin <manikulin@gmail.com> - 2024-12-10 04:50 +0100
                              Re: ext4 FS Crash Daniel Harris <mail.dharris@googlemail.com> - 2025-01-13 16:30 +0100
      Re: ext4 FS Crash Jeffrey Walton <noloader@gmail.com> - 2024-12-04 22:00 +0100
        Re: ext4 FS Crash Klaus Singvogel <deb-user-ml@singvogel.net> - 2024-12-05 08:30 +0100
          Re: ext4 FS Crash gene heskett <gheskett@shentel.net> - 2024-12-05 11:10 +0100
            Re: ext4 FS Crash Klaus Singvogel <deb-user-ml@singvogel.net> - 2024-12-05 13:10 +0100
              Re: ext4 FS Crash gene heskett <gheskett@shentel.net> - 2024-12-05 13:40 +0100
                Re: ext4 FS Crash Michael Stone <mstone@debian.org> - 2024-12-05 14:00 +0100
                Re: ext4 FS Crash Klaus Singvogel <deb-user-ml@singvogel.net> - 2024-12-05 15:00 +0100
                  Re: ext4 FS Crash gene heskett <gheskett@shentel.net> - 2024-12-05 22:30 +0100
    Re: ext4 FS Crash Jeffrey Walton <noloader@gmail.com> - 2024-12-04 18:20 +0100

Page 1 of 2  [1] 2  Next page →

#275226 — ext4 FS Crash

[Multipart message — attachments visible in raw view] — view raw

Hello

I have been using the stable branch but recently it has not been so
stable.  I have experienced some unexpected behavior Not sure if its
related to this ubuntu bug (
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1805816 )

Seeing the similarity especially that we are both using similar drives
(mine i( Samsung SSD 980 PRO 1TB)  makes me think it might be a hardware
instead of a software issue.

Anyway its interesting that it has only started recently.  Different kernel
possibly?

Not sure if I can attach a picture of the error messages but some of the
errors are
ext4_find_entry
ext4_journal_check_start
ext4_setattr
mounting filesystem read-only

I have done a file system check and everything seems ok and the drive
doesn't have any error messages and journalctl doesn't seem to log any
errors (not that i can find anyway).

I will have to disable the apst but i just thought this bug might have been
fixed from 2018 but maybe not.

ps my system is a desktop system not a laptop if that makes a difference.

Thanks Dan

[toc] | [next] | [standalone]

#275227

[Multipart message — attachments visible in raw view] — view raw

Daniel Harris:
> 
> Not sure if I can attach a picture of the error messages but some of the
> errors are
> ext4_find_entry
> ext4_journal_check_start
> ext4_setattr
> mounting filesystem read-only

Please do not send any attachments here. I suggest you just copy and
paste the log messages from journalctl or wherever you can find them. It
is really hard to say anything specific without those messages.

> I have done a file system check and everything seems ok and the drive
> doesn't have any error messages and journalctl doesn't seem to log any
> errors (not that i can find anyway).

Have you tried 'journalctl --dmesg'?

> ps my system is a desktop system not a laptop if that makes a difference.

I do not think this matters here.

J.
-- 
I wish I had been aware enough to enjoy my time as a toddler.
[Agree]   [Disagree]
                 <http://archive.slowlydownward.com/NODATA/data_enter2.html>

[toc] | [prev] | [next] | [standalone]

#275232

On Wednesday, 4 December 2024 09:29:17 -03 Daniel Harris wrote:
> Hello
>
> I have been using the stable branch but recently it has not been so
> stable.  I have experienced some unexpected behavior Not sure if its
> related to this ubuntu bug (
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1805816 )
>
> Seeing the similarity especially that we are both using similar drives
> (mine i( Samsung SSD 980 PRO 1TB)  makes me think it might be a
> hardware instead of a software issue.
>
> Anyway its interesting that it has only started recently.  Different
> kernel possibly?
>
> Not sure if I can attach a picture of the error messages but some of
> the errors are
> ext4_find_entry
> ext4_journal_check_start
> ext4_setattr
> mounting filesystem read-only
>
> I have done a file system check and everything seems ok and the drive
> doesn't have any error messages and journalctl doesn't seem to log any
> errors (not that i can find anyway).
>
> I will have to disable the apst but i just thought this bug might have
> been fixed from 2018 but maybe not.
Kernel 4.19  I'd be very surprised if that would be related.
>
> ps my system is a desktop system not a laptop if that makes a
> difference.
>
> Thanks Dan

Hello Dan,

I am using the exact same drive Samsung SSD 980 PRO 1TB in my desktop
and in my laptop.
Desktop with Debian Sid
Laptop with Ubuntu 24 LTS (TUXEDO)
Neither one nor the other has experienced ext4 FS crashes

I'd save my data a.s.a.p. and install a new NVME drive if I were in your
shoes.

have a nice day
--
Eike Lantzsch KY4PZ / ZP5CGE

[toc] | [prev] | [next] | [standalone]

#275252

On Wed, Dec 04, 2024 at 11:34:41AM -0300, Eike Lantzsch ZP5CGE / KY4PZ wrote:
> On Wednesday, 4 December 2024 09:29:17 -03 Daniel Harris wrote:
> > Hello
> >
> > I have been using the stable branch but recently it has not been so
> > stable.  I have experienced some unexpected behavior Not sure if its
> > related to this ubuntu bug (
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1805816 )
> >
> > I have done a file system check and everything seems ok and the drive
> > doesn't have any error messages and journalctl doesn't seem to log any
> > errors (not that i can find anyway).
> >
> > I will have to disable the apst but i just thought this bug might have
> > been fixed from 2018 but maybe not.
> Kernel 4.19  I'd be very surprised if that would be related.

Agreed - that's the Buster (Debian 10) kernel not the current kernel.
> >
> >
> > Thanks Dan
> 
> I'd save my data a.s.a.p. and install a new NVME drive if I were in your
> shoes.
> 
> have a nice day
> --
> Eike Lantzsch KY4PZ / ZP5CGE
>

All best, as ever,

Andy Cater
(amacater@debian.org) 
> 
> 

[toc] | [prev] | [next] | [standalone]

#275241

[Multipart message — attachments visible in raw view] — view raw

On 04.12.2024 17:29, Daniel Harris wrote:
> Hello
>
> I have been using the stable branch but recently it has not been so 
> stable.  I have experienced some unexpected behavior Not sure if its 
> related to this ubuntu bug ( 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1805816 )
>
> Seeing the similarity especially that we are both using similar drives 
> (mine i( Samsung SSD 980 PRO 1TB)  makes me think it might be a 
> hardware instead of a software issue.
>
> Anyway its interesting that it has only started recently. Different 
> kernel possibly?
>
I use Linux kernel from stable and ext4 filesystems on many PCs with 
NVMe and SATA SSDs and have not noticed anything fishy.
It is possible that symptoms you describe could be caused by regression 
bug in kernel which leads to data corruption, but it is more likely you 
have a faulty hardware instead.
First make sure you have a good backup of your data from Samsung drive.
Next you could see if there is a firmware update available for your 
drive model at Samsung website. [1]
Firmware bug could surface later on and cause data corruption and it is 
a good idea in general to keep storage firmware up-to-date.


[1] 
https://semiconductor.samsung.com/consumer-storage/support/tools/#Samsung%20Storage%20Firmware
-- 

  With kindest regards, Alexander.

  Debian - The universal operating system
  https://www.debian.org

[toc] | [prev] | [next] | [standalone]

#275242

Daniel Harris wrote:
> Seeing the similarity especially that we are both using similar drives
> (mine i( Samsung SSD 980 PRO 1TB)  makes me think it might be a hardware
> instead of a software issue.

The referenced Samsung SSD 980 PRO has a critical firmware bug.

This bug hit me too. I had to replace my broken SSD by a new one, via the Samsung support.
I use a full-disk encryption, and therefore had a data loss - up to my last backup (5 days ago).

Some more details here:
https://www.pugetsystems.com/support/guides/critical-samsung-ssd-firmware-update/


Best regards,
	Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

[toc] | [prev] | [next] | [standalone]

#275246

[Multipart message — attachments visible in raw view] — view raw

Thanks for all your replies.
As far as I can tell there are no errors reported using fsck or smartctl or
nvme
 and the firmware is the correct and newest version so no problems there.

The following are the messages that appear but only taken from my phone and
copied from the photo (lots of scrolling errors repeating over).
I thought these new drives were supposed to last longer than older moving
HDD but obviously not

I guess its time to buy a new drive : (

EXT4-fs  (nvme0n1p2): Remounting filesystem read-onty
EXT4-fs  error (device nvme01p2): ext4_journal_check_start:83: comm
systemd-journal: Detected aborted Jounal
[633582.907324] EXT4-fs error (device nvme0n1p2): _ext4_find_entry:1683:
inode #5898248: comm ntpd: reading directory iblock 0
[633582 908250] EXT4-fs (nvme0n1p2) : Remounting filesystem read-only
EXT4-fs (nvme0n1p2): Remounting filesystem read-only


EXT4-fs error (device nvme0n1p2) : ext4_journal.check_start:83: comm
systemd-journal: Detected aborted journal
[633582.912099] EXT4-fs (nvme0n1p2): Remounting filesystem read-only
EXT4-fs error (device nvme0n1p2): ext4_journal-check_start:83: comm
systemd-journal: Detected aborted journal
[633582.916126] EXT4-fs (nvme0n1p2): Remounting filesystem read-only

(633583.797550) EXT4-fs error (device nvme0n1p2) in ext4_setattr:5628: ——
Journal has aborted
(633583. 798466) EXT4-fs (nvme0n1p2): Remounting filesystem read-only
EXT4-fs  error (device nvme01p2): ext4_journal_check_start:83: comm
systemd-journal: Detected aborted Jounal
EXT4-fs (nvme@nip2): Remounting filesystem read-only


EXT4-fs error (device nvme0n1p2): _ext4_find_entry:1683: inode #1966081:
comm cron: reading directory Iblock 0
EXT4-fs (nvme@nip2): Remounting filesystem read-only
EXT4-fs error (device nvme0n1p2) in ext4_setattr:5628: —— Journal has
aborted
EXT4-fs (nvme@nip2): Remounting filesystem read-only



On Wed, Dec 4, 2024 at 4:39 PM Klaus Singvogel <deb-user-ml@singvogel.net>
wrote:

> Daniel Harris wrote:
> > Seeing the similarity especially that we are both using similar drives
> > (mine i( Samsung SSD 980 PRO 1TB)  makes me think it might be a hardware
> > instead of a software issue.
>
> The referenced Samsung SSD 980 PRO has a critical firmware bug.
>
> This bug hit me too. I had to replace my broken SSD by a new one, via the
> Samsung support.
> I use a full-disk encryption, and therefore had a data loss - up to my
> last backup (5 days ago).
>
> Some more details here:
>
> https://www.pugetsystems.com/support/guides/critical-samsung-ssd-firmware-update/
>
>
> Best regards,
>         Klaus.
> --
> Klaus Singvogel
> GnuPG-Key-ID: 1024R/5068792D  1994-06-27
>

[toc] | [prev] | [next] | [standalone]

#275259

On Wed, Dec 04, 2024 at 05:11:47PM +0000, Daniel Harris wrote:
>Thanks for all your replies.
>As far as I can tell there are no errors reported using fsck or smartctl or
>nvme
> and the firmware is the correct and newest version so no problems there.
>
>The following are the messages that appear but only taken from my phone and
>copied from the photo (lots of scrolling errors repeating over).
>I thought these new drives were supposed to last longer than older moving HDD
>but obviously not

Is this during boot? The messages indicate a corrupted journal, which 
generally means a device error, or maybe a device which lost power while 
writing. It should be possible to mount read-only without replaying the 
journal for recovery purposes, but it's basically unfixable.

>I guess its time to buy a new drive : (

Did you try "nvme smart-log /dev/nvme0" to look for issues?

[toc] | [prev] | [next] | [standalone]

#275272

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 4, 2024 at 11:43 PM Michael Stone <mstone@debian.org> wrote:

> On Wed, Dec 04, 2024 at 05:11:47PM +0000, Daniel Harris wrote:
> >Thanks for all your replies.
> >As far as I can tell there are no errors reported using fsck or smartctl
> or
> >nvme
> > and the firmware is the correct and newest version so no problems there.
> >
> >The following are the messages that appear but only taken from my phone
> and
> >copied from the photo (lots of scrolling errors repeating over).
> >I thought these new drives were supposed to last longer than older moving
> HDD
> >but obviously not
>
> Is this during boot? The messages indicate a corrupted journal, which
> generally means a device error, or maybe a device which lost power while
> writing. It should be possible to mount read-only without replaying the
> journal for recovery purposes, but it's basically unfixable.
>

So its not actually a crash.  On the 2 occasions it has happened, I have
been away from my computer for a while, and when I return and move the
mouse, I can see messages scrolling on a black screen (no X running).  I
can move to a new vt but I cannot log in.  When I try to log in I just get
the errors repeating on the screen.  After I do a hard reset everything
works perfectly. No errors anywhere.


> >I guess its time to buy a new drive : (
>
> Did you try "nvme smart-log /dev/nvme0" to look for issues?
>
>
seems normal to me

 Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                        : 0
temperature                             : 31°C (304 Kelvin)
available_spare                         : 100%
available_spare_threshold               : 10%
percentage_used                         : 0%
endurance group critical warning summary: 0
Data Units Read                         : 807,634 (413.51 GB)
Data Units Written                      : 5,680,746 (2.91 TB)
host_read_commands                      : 6,573,734
host_write_commands                     : 75,990,191
controller_busy_time                    : 1,145
power_cycles                            : 618
power_on_hours                          : 197
unsafe_shutdowns                        : 21
media_errors                            : 0
num_err_log_entries                     : 0
Warning Temperature Time                : 0
Critical Composite Temperature Time     : 0
Temperature Sensor 1           : 31°C (304 Kelvin)
Temperature Sensor 2           : 38°C (311 Kelvin)
Thermal Management T1 Trans Count       : 0
Thermal Management T2 Trans Count       : 0
Thermal Management T1 Total Time        : 0
Thermal Management T2 Total Time        : 0


Thanks Dan

[toc] | [prev] | [next] | [standalone]

#275274

On Thu, Dec 05, 2024 at 10:53:54AM +0000, Daniel Harris wrote:
>So its not actually a crash.  On the 2 occasions it has happened, I have been
>away from my computer for a while, and when I return and move the mouse, I can
>see messages scrolling on a black screen (no X running).  I can move to a new
>vt but I cannot log in.  When I try to log in I just get the errors repeating
>on the screen.  After I do a hard reset everything works perfectly. No errors
>anywhere.

Have you tried a memory test? Those symptoms and the smart output make 
me think the problem is in hardware other than the drive itself. Memory 
is the easiest to check and the easiest to remedy.

[toc] | [prev] | [next] | [standalone]

#275284

[Multipart message — attachments visible in raw view] — view raw

On Thu, Dec 5, 2024 at 12:33 PM Michael Stone <mstone@debian.org> wrote:

> On Thu, Dec 05, 2024 at 10:53:54AM +0000, Daniel Harris wrote:
> >So its not actually a crash.  On the 2 occasions it has happened, I have
> been
> >away from my computer for a while, and when I return and move the mouse,
> I can
> >see messages scrolling on a black screen (no X running).  I can move to a
> new
> >vt but I cannot log in.  When I try to log in I just get the errors
> repeating
> >on the screen.  After I do a hard reset everything works perfectly. No
> errors
> >anywhere.
>
> Have you tried a memory test? Those symptoms and the smart output make
> me think the problem is in hardware other than the drive itself. Memory
> is the easiest to check and the easiest to remedy.
>
> Memtest passed with no errors

Thanks
Dan

[toc] | [prev] | [next] | [standalone]

#275268

There are two things which could be tried with the SSD

1. SSD's have some self healing capacities (discarding defect sectors) which are 
performed when the drive is not mounted. Therefore, enter the BIOS of the 
computer and let it running for ca. an hour. Then restart the computer.

2. After making a backup, do a "secure erase" of the SSD. Of course that needs 
reformatting the drive and rebuilding the system. I was able to revive a Samsung 
960 Pro this way.

Regards,
Jörg.

[toc] | [prev] | [next] | [standalone]

#275282

On 05/12/2024 16:19, Jörg-Volker Peetz wrote:
> 1. SSD's have some self healing capacities (discarding defect sectors) 
> which are performed when the drive is not mounted. Therefore, enter the 
> BIOS of the computer and let it running for ca. an hour. Then restart 
> the computer.

I am curious which way OS notifies a drive that it is mounted. I 
believed that drivers read and write blocks, maybe switch power save 
states, but mount is performed on a higher level.

[toc] | [prev] | [next] | [standalone]

#275283

On Thu, Dec 05, 2024 at 04:26:18PM CET, Max Nikulin <manikulin@gmail.com> said:
> On 05/12/2024 16:19, Jörg-Volker Peetz wrote:
> > 1. SSD's have some self healing capacities (discarding defect sectors)
> > which are performed when the drive is not mounted. Therefore, enter the
> > BIOS of the computer and let it running for ca. an hour. Then restart
> > the computer.
> 
> I am curious which way OS notifies a drive that it is mounted. I believed
> that drivers read and write blocks, maybe switch power save states, but
> mount is performed on a higher level.
> 

We would the drive need to be notified ?

-- 
Erwan David

[toc] | [prev] | [next] | [standalone]

#275287

Hi,

On Thu, Dec 05, 2024 at 04:32:30PM +0100, Erwan David wrote:
> On Thu, Dec 05, 2024 at 04:26:18PM CET, Max Nikulin <manikulin@gmail.com> said:
> > On 05/12/2024 16:19, Jörg-Volker Peetz wrote:
> > > 1. SSD's have some self healing capacities (discarding defect sectors)
> > > which are performed when the drive is not mounted. Therefore, enter the
> > > BIOS of the computer and let it running for ca. an hour. Then restart
> > > the computer.
> > 
> > I am curious which way OS notifies a drive that it is mounted. I believed
> > that drivers read and write blocks, maybe switch power save states, but
> > mount is performed on a higher level.
> 
> We would the drive need to be notified ?

Jörg-Volker claimed that there were self-healing routines that only
happen when an SSD is not mounted.

I am highly skeptical.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#275324

On 12/5/24 10:33, Erwan David wrote:
> On Thu, Dec 05, 2024 at 04:26:18PM CET, Max Nikulin <manikulin@gmail.com> said:
>> On 05/12/2024 16:19, Jörg-Volker Peetz wrote:
>>> 1. SSD's have some self healing capacities (discarding defect sectors)
>>> which are performed when the drive is not mounted. Therefore, enter the
>>> BIOS of the computer and let it running for ca. an hour. Then restart
>>> the computer.
>>
>> I am curious which way OS notifies a drive that it is mounted. I believed
>> that drivers read and write blocks, maybe switch power save states, but
>> mount is performed on a higher level.
>>
> 
> We would the drive need to be notified ?
Wrong question IMO. If as you say, and that makes perfect sense, if the 
drive is boot mounted, there s/b a mechanism to advise the user that the 
boot mount will be delayed until such time as the drive reports its 
validation is completed. That would serve the purpose of advising the 
user that its use-by date is rapidly approaching. As is, we are at the 
mercy of the drive maker until it goes RO. And that most certainly is 
not a desirable situation.

I think the case with u-sd's used for nearly everything in the arm 
arena, seem to be capable of doing this "housekeeping" while mounted is 
a good thing as I only power them down to do my mods, and my failure 
rate on those is actually much better. A kill-a-watt says my rebuilt but 
standing idle between jobs printers is drawing 14 watts. The pi clones 
have had zero u-sd card failures in over a decade..

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#275292

On Thu, Dec 05, 2024 at 10:26:18PM +0700, Max Nikulin wrote:
>On 05/12/2024 16:19, Jörg-Volker Peetz wrote:
>>1. SSD's have some self healing capacities (discarding defect 
>>sectors) which are performed when the drive is not mounted. 
>>Therefore, enter the BIOS of the computer and let it running for ca. 
>>an hour. Then restart the computer.
>
>I am curious which way OS notifies a drive that it is mounted. I 
>believed that drivers read and write blocks, maybe switch power save 
>states, but mount is performed on a higher level.

It doesn't: leaving the system unmounted ensures that the drive is idle, 
but in general that's not necessary--just leaving the system alone will 
usually have the same result unless you've got a runaway process chewing 
on the disk. The SSD will do maintenance tasks when it's idle, or under 
pressure (has no other choice because there are no writable blocks 
available).

The relevant limitation is that an SSD physical block can only be 
written once and then needs to be erased before another write. Changing 
a logical block writing the logical block to a different physical 
location. Physical blocks vary in size but are many times the size of a 
512 byte logically-addressible block. Many logical blocks (or versions 
of the same logical block) can be written to a physical block, and 
logical blocks that change leave unused older copies on the physical 
block. The entire physical block must be erased to write anything to the 
now-unused portions. This means copying all of the in-use logical blocks 
to a different physical block before erasing the original physical 
block. The drive will try to keep a pool of writable physical locations, 
and has a cache of faster storage to hold data pending a write to slower 
storage. Ideally your writes fit in cache, and the drive can do the 
erasing and moving when the drive is idle. If you write more data than 
can be cached, and there are no erased blocks to move data into, the 
drive needs to relocate existing logical blocks to free up and erase 
physical blocks before writing the new data. This has a significant 
performance impact if you're trying to write faster than the drive can 
relocate/erase.

If you use fstrim/discard you'll notify the drive that certain logical 
blocks are not in use, allowing the physical block to be erased without 
the need to read & relocate those logical blocks. A block is marked 
unavailable/bad if it fails, and won't be used again. This will happen 
transparently if a block fails on erase/write (the data will simply be 
written to a different physical block and the logical block is 
unaffected). The drive will also notice if a physical block is readable 
but degrading, and will stop using it once any logical blocks it 
contains are written to a new physical block. If a block totally fails 
on read (much less common) it can't be relocated and the OS will get 
very non-transparent errors every time it tries to read that logical 
block. If you have a logical block that can't be read, discarding it can 
effectively make it disappear (i.e., the drive marks it as unused 
without needing to read it, and it will be available after it is written 
to again). You may be able to revitalize a drive with a troublesome bad 
block (e.g., underneath a directory entry so it can't be deleted and 
trimmed) by trimming the entire drive and restoring from backup. This is 
rare; in hundreds of TB of SSD I've encountered that situation exactly 
once. In that case it may be just a fluke that won't reoccur, but 
probably I wouldn't use that drive again (but if it was just a fluke, 
the drive is likely fine and not using it is overly paranoid; the right 
course of action is dependent on budget and risk tolerance).

[toc] | [prev] | [next] | [standalone]

#275337

Hi,

Michael Stone wrote on 05/12/2024 18:41:
> On Thu, Dec 05, 2024 at 10:26:18PM +0700, Max Nikulin wrote:
>> On 05/12/2024 16:19, Jörg-Volker Peetz wrote:
>>> 1. SSD's have some self healing capacities (discarding defect sectors) which 
>>> are performed when the drive is not mounted. Therefore, enter the BIOS of the 
>>> computer and let it running for ca. an hour. Then restart the computer.
>>
>> I am curious which way OS notifies a drive that it is mounted. I believed that 
>> drivers read and write blocks, maybe switch power save states, but mount is 
>> performed on a higher level.
> 
> It doesn't: leaving the system unmounted ensures that the drive is idle, but in 
> general that's not necessary--just leaving the system alone will usually have 
> the same result unless you've got a runaway process chewing on the disk. The SSD 
> will do maintenance tasks when it's idle, or under pressure (has no other choice 
> because there are no writable blocks available).

Should have been more clear. The drive should be idle for a longer time. This is 
assured by not mounting any partition of the SSD.
I was able to "repair" unreadable sectors on a built-in SSD of an HP-Probook 
laptop. As far as I remember I also deleted files which could not be read any 
more because of defective sectors and restored the files from backup. Such 
unreadable files can be found by performing, e.g., a checksum calculation of all 
files on the SSD. Then, leaving the SSD alone, it was able to "replace" the 
defective sectors by spare sectors.

Regards,
Jörg.

[toc] | [prev] | [next] | [standalone]

#275338

On Fri, Dec 06, 2024 at 02:26:23PM +0100, Jörg-Volker Peetz wrote:
>Should have been more clear. The drive should be idle for a longer 
>time. This is assured by not mounting any partition of the SSD.
>I was able to "repair" unreadable sectors on a built-in SSD of an 
>HP-Probook laptop. As far as I remember I also deleted files which 
>could not be read any more because of defective sectors and restored 
>the files from backup. Such unreadable files can be found by 
>performing, e.g., a checksum calculation of all files on the SSD. 
>Then, leaving the SSD alone, it was able to "replace" the defective 
>sectors by spare sectors.

Sorry, I don't buy that. Whatever happened, it wasn't the drive 
pondering unreadable sectors and then regenerating them. I can believe 
that deleting unreadable files and restoring them made them readable 
again. (Overwriting a bad sector will cause the original block to be 
freed and potentially discarded; after rewriting, the data is not in the 
same physical location it was before.) As outlined in a previous post, 
trimming unused space may also let the drive discard bad blocks. None of 
that requires the drive to be unmounted.

[toc] | [prev] | [next] | [standalone]

#275339

Hi,

Michael Stone wrote on 06/12/2024 14:49:
> On Fri, Dec 06, 2024 at 02:26:23PM +0100, Jörg-Volker Peetz wrote:
>> Should have been more clear. The drive should be idle for a longer time. This 
>> is assured by not mounting any partition of the SSD.
>> I was able to "repair" unreadable sectors on a built-in SSD of an HP-Probook 
>> laptop. As far as I remember I also deleted files which could not be read any 
>> more because of defective sectors and restored the files from backup. Such 
>> unreadable files can be found by performing, e.g., a checksum calculation of 
>> all files on the SSD. Then, leaving the SSD alone, it was able to "replace" 
>> the defective sectors by spare sectors.
> 
> Sorry, I don't buy that. Whatever happened, it wasn't the drive pondering 
> unreadable sectors and then regenerating them. I can believe that deleting 
> unreadable files and restoring them made them readable again. (Overwriting a bad 
> sector will cause the original block to be freed and potentially discarded; 
> after rewriting, the data is not in the same physical location it was before.) 

Yes, you are right. I also called 'fstrim -a' before restarting the computer 
into BIOS.

> As outlined in a previous post, trimming unused space may also let the drive 
> discard bad blocks. None of that requires the drive to be unmounted.
> 
May be that would have worked if I had waited long enough. But I did it by 
letting the computer stay in BIOS for a while.

As a check if the defective sectors are all mapped out I did read all sectors of 
the partitions:

   sudo dd if=/dev/sdaX of=/dev/null bs=8M status=progress

Regards,
Jörg.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web