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


Groups > linux.debian.user > #275405

Re: ext4 FS Crash

From Max Nikulin <manikulin@gmail.com>
Newsgroups linux.debian.user
Subject Re: ext4 FS Crash
Date 2024-12-08 17:30 +0100
Message-ID <JRskp-eQbE-5@gated-at.bofh.it> (permalink)
References (6 earlier) <JQGz8-ebyf-15@gated-at.bofh.it> <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>
Organization linux.* mail to news gateway

Show all headers | View raw


On 06/12/2024 23:31, Michael Stone wrote:
> On Fri, Dec 06, 2024 at 10:51:20PM +0700, Max Nikulin wrote:
>> Michael, thank you for the long message. Actually I wonder what is 
>> "idle" that allows drive to perform self-maintenance. I expect that 
>> the device should not be in some deep power saving state (I am yet to 
>> discover available tunables that allows drive to "sleep"). Should it 
>> be some period of time (seconds? minutes?) completely without any IO 
>> or is it enough if read/write speed is below some threshold and from/ 
>> to another chip?
> 
> Basically it means that it isn't busy doing I/O; if you're reading or 
> writing, the drive can't also be reading and writing. It doesn't need to 
> be absolutely unused.

Accidentally I noticed a link suggesting that USB enclosure may be more 
effective than booting to system firmware menu. I am curious if it is 
just an invention of support staff or it is blessed by SSD firmware 
developers:

<https://www.crucial.com/support/articles-faq-ssd/why-did-ssd-disappear-from-system>
"Why Did my SSD 'Disappear' from my System?"

My experience is that at least USB enclosures for HDD may be quite 
aggressive in respect to power saving. It is linked from
<https://www.truenas.com/community/threads/killed-an-nvme-drive-running-a-long-smart-test.114125/>
"Killed an NVMe drive running a long SMART test" Nov 11, 2023

>> As to erase block size, I am aware of it. On the other hand I am 
>> surprised that a drive does not allow kernel to optimize writes on a 
>> higher level (as uSD does):
>>
>> grep '' /sys/block/*/queue/discard_granularity
>> ...
>> /sys/block/mmcblk0/queue/discard_granularity:4194304
>> /sys/block/nvme0n1/queue/discard_granularity:4096
>> /sys/block/sda/queue/discard_granularity:4096  # hdd (shingled)

I do not think it is relevant, but sorry for the confusion concerning 
"shingled", it is not. This disk has another issue: short heads 
unloading timeout that is not configurable using hdparm.

> The discard_granularity *limits* how the kernel can tell the drive that 
> there are free blocks--a granularity of 4M means that the kernel can 
> only issue a TRIM command when it has at least 4M of empty space *and* 
> that empty space is aligned on a 4M boundary. (That is, you can't 
> discard locations 2-5M on the drive, only 0-3M, 4-7M, etc.) It's a big 
> number on the sd card because sd cards are pretty much junk. On a decent 
> NVMe drive it'll typically be 512 (i.e., you can discard any logical 
> block) or maybe 4096 if you're in 4k mode.

I switched this NVME drive to 4k mode. However I considered your message 
as statement that internally drives still use higher erase block size
<https://lists.debian.org/msgid-search/cc8f9e0a-b31f-11ef-9b6a-00163eeb5320@msgid.mathom.us>
Thu, 5 Dec 2024 12:41:55 -0500

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