Re: ext4 FS Crash

From	Michael Stone <mstone@debian.org>
Newsgroups	linux.debian.user
Subject	Re: ext4 FS Crash
Date	2024-12-05 18:50 +0100
Message-ID	<JQo9b-dXPx-3@gated-at.bofh.it> (permalink)
References	<JPWFX-dGq6-9@gated-at.bofh.it> <JQ0JA-dIUe-21@gated-at.bofh.it> <JQ1cB-dJjO-9@gated-at.bofh.it> <JQglj-dT03-7@gated-at.bofh.it> <JQlXH-dWpk-1@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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).

Thread

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

csiph-web