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


Groups > linux.debian.user > #275406

Re: ext4 FS Crash

From Michael Stone <mstone@debian.org>
Newsgroups linux.debian.user
Subject Re: ext4 FS Crash
Date 2024-12-08 18:20 +0100
Message-ID <JRt6N-eRX3-9@gated-at.bofh.it> (permalink)
References (5 earlier) <JQH2a-ec1x-23@gated-at.bofh.it> <JQHbP-ecqG-5@gated-at.bofh.it> <JQIUh-ee9P-11@gated-at.bofh.it> <JQJx0-eeCN-9@gated-at.bofh.it> <JRskp-eQbE-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Sun, Dec 08, 2024 at 11:26:51PM +0700, Max Nikulin wrote:
>I switched this NVME drive to 4k mode. However I considered your 
>message as statement that internally drives still use higher erase 
>block size

The erase block is going to be many megabytes, it has nothing to do with 
the logical blocks. The erase block isn't erased as each logical block 
is written, it is erased when it's empty. Many logical blocks can be 
written (sequentially) over time to the same erase block. Some drives 
work better with 4k logical blocks but in general I don't recommend 
using them--having a mix of 4k and 512b blocks on a system is a bit of a 
pain, and it makes replacing a drive more complicated. Not all drives 
support 4k, and many that do get no benefit from such a configuration. 
E.g.:

# nvme id-ns -H /dev/nvme0n1 | grep Rel
LBA Format  0 : Metadata Size: 0   bytes - Data Size: 512 bytes - Relative Performance: 0 Best (in use)
LBA Format  1 : Metadata Size: 0   bytes - Data Size: 4096 bytes - Relative Performance: 0 Best 

This drive supports either format, but both are "Best". Other drives 
will recommend one or the other:

# nvme id-ns -H /dev/nvme0n1 | grep Rel
LBA Format  0 : Metadata Size: 0   bytes - Data Size: 512 bytes - Relative Performance: 0x2 Good (in use)
LBA Format  1 : Metadata Size: 0   bytes - Data Size: 4096 bytes - Relative Performance: 0x1 Better 

Or support only one:

# nvme id-ns -H /dev/nvme1n1 | grep Rel
LBA Format  0 : Metadata Size: 0   bytes - Data Size: 512 bytes - Relative Performance: 0 Best (in use)

I'd rather just stick with 512b and not worry about it. Of the drives 
above, the one which doesn't care is the newest/fastest. It likely 
supports 4k format because it's a U.3 drive which could be used in a 
storage array already configured for 4k. The other two are in the same 
LVM VG, and if one of them were formatted 4k I wouldn't be able to 
migrate volumes between them (so any possible, likely not noticeable, 
performance benefit from a 4k format would be outweighed by the 
inconvenience.) The one that recommends a 4k format is the oldest, 
smallest, and slowest by far (Gen3 vs Gen4) and at best is half the 
speed of the others, regardless of format.

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


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