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 2 of 2 — ← Prev page 1 [2]

#275341

On 06/12/2024 21:05, Jörg-Volker Peetz wrote:
> 
> 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

I am curious if "nvme device-self-test" might be more effective.

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?

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)

Earlier I heard that firmware of some (USB, SD) flash drives is 
optimized for FAT. It sounded like a magic. I was afraid that it might 
have some detrimental effect on LUKS-encrypted ext4 partition. Later I 
read that it is just some storage region with small erase block size. 
This region may be small in comparison to total capacity, but it is 
enough to fit frequently overwritten FAT structures. In this form it is 
more convincing.

I do not try to dispute that some kind of self-healing may happen, but I 
do not believe in "not mounted" state. "Idle" is not precise from my 
point of view. No (or limited) IO is reasonable, but some initialization 
might be required to ensure power saving settings.

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

#275343

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.

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

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.

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

#275405

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

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

#275406

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.

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

#275449

On 09/12/2024 00:14, Michael Stone wrote:
> Not all drives 
> support 4k, and many that do get no benefit from such a configuration. 
[...]
> # 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

It is my case. I decided that ext4 uses 4k blocks anyway, so it is 
better to be consistent with hardware&firmware developers.

As to erase block size, my expectation is that some drivers might 
benefit if that size is known: flushing caches (especially in laptop 
mode), allocating space for new files. I have no evidences that it is 
implemented though. Perhaps dedicated chips and caches inside drives may 
do it more efficiently (besides dumb cheap models).

mkfs.* tools might use erase block size to align filesystem structures.

It is the reason why I was surprised that erase block size is not 
exposed to kernel.

My real curiosity was caused by "not mounting" a drive to allow self 
healing. "Idle" is imprecise from my point of view, but I think we may 
stop here. There is a chance that I will accidentally notice a detailed 
article on this topic.

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

#276509

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

Just an Update to this thread.

It was actually a software bug in desktop-portal (or something like that).
Once that was removed my system has been rock solid.

Thanks Dan


On Tue, Dec 10, 2024 at 3:41 AM Max Nikulin <manikulin@gmail.com> wrote:

> On 09/12/2024 00:14, Michael Stone wrote:
> > Not all drives
> > support 4k, and many that do get no benefit from such a configuration.
> [...]
> > # 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
>
> It is my case. I decided that ext4 uses 4k blocks anyway, so it is
> better to be consistent with hardware&firmware developers.
>
> As to erase block size, my expectation is that some drivers might
> benefit if that size is known: flushing caches (especially in laptop
> mode), allocating space for new files. I have no evidences that it is
> implemented though. Perhaps dedicated chips and caches inside drives may
> do it more efficiently (besides dumb cheap models).
>
> mkfs.* tools might use erase block size to align filesystem structures.
>
> It is the reason why I was surprised that erase block size is not
> exposed to kernel.
>
> My real curiosity was caused by "not mounting" a drive to allow self
> healing. "Idle" is imprecise from my point of view, but I think we may
> stop here. There is a chance that I will accidentally notice a detailed
> article on this topic.
>
>
>

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

#275255

On Wed, Dec 4, 2024 at 2:47 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/

That's interesting (in a morbid sort of way).

Do you know if fwupdmgr will detect out-of-date firmware on the drives?

Jeff

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

#275266

Jeffrey Walton wrote:
> On Wed, Dec 4, 2024 at 2:47 PM Klaus Singvogel wrote:
> >
> > Some more details here:
> > https://www.pugetsystems.com/support/guides/critical-samsung-ssd-firmware-update/
> 
> That's interesting (in a morbid sort of way).
> 
> Do you know if fwupdmgr will detect out-of-date firmware on the drives?

I'm sorry, but I don't know. I only became aware of fwupdmgr afterwards.

At least the replacement Samsung SSD was detected by fwupdmgr on my last run.

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

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

#275270

On 12/5/24 02:23, Klaus Singvogel wrote:
> Jeffrey Walton wrote:
>> On Wed, Dec 4, 2024 at 2:47 PM Klaus Singvogel wrote:
>>>
>>> Some more details here:
>>> https://www.pugetsystems.com/support/guides/critical-samsung-ssd-firmware-update/
>>
>> That's interesting (in a morbid sort of way).
>>
>> Do you know if fwupdmgr will detect out-of-date firmware on the drives?
> 
> I'm sorry, but I don't know. I only became aware of fwupdmgr afterwards.
> 
> At least the replacement Samsung SSD was detected by fwupdmgr on my last run.
> 
> Best regards,
> 	Klaus.
interesting comments here. I've been using SSD's since 40G was the 
biggest. The 256G spinning rust, now 15 years old is the only spinning 
rust left here. And I've drawer full of samsung 860-870 series drives 
that have all gone wonky but not RO yet.. I now have a mixture of stuff 
from Taiwan in 2T and 4T sizes, all healthy. I guess I was not the only 
one that got questionable drives from Samsung. This is the first time 
I've seen them discussed in this context. Thank you for saying something 
out loud.

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]

#275273

Hi Gene,

gene heskett wrote:
> interesting comments here. I've been using SSD's since 40G was the biggest.
> The 256G spinning rust, now 15 years old is the only spinning rust left
> here. And I've drawer full of samsung 860-870 series drives that have all
> gone wonky but not RO yet.. I now have a mixture of stuff from Taiwan in 2T
> and 4T sizes, all healthy. I guess I was not the only one that got
> questionable drives from Samsung. This is the first time I've seen them
> discussed in this context. Thank you for saying something out loud.

To point this out: it was only exactly this model from Samsung: SSD 980 PRO, which isn't working properly.
Repeat: only Samsung SSD 980 PRO.

It can be fixed by a Firmware upgrade, and more recently charges of Samsung SSD 980 PRO are flashed/sold with a good Firmware out-of-the-box.

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

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

#275275

On 12/5/24 06:59, Klaus Singvogel wrote:
> Hi Gene,
> 
> gene heskett wrote:
>> interesting comments here. I've been using SSD's since 40G was the biggest.
>> The 256G spinning rust, now 15 years old is the only spinning rust left
>> here. And I've drawer full of samsung 860-870 series drives that have all
>> gone wonky but not RO yet.. I now have a mixture of stuff from Taiwan in 2T
>> and 4T sizes, all healthy. I guess I was not the only one that got
>> questionable drives from Samsung. This is the first time I've seen them
>> discussed in this context. Thank you for saying something out loud.
> 
> To point this out: it was only exactly this model from Samsung: SSD 980 PRO, which isn't working properly.
> Repeat: only Samsung SSD 980 PRO.
> 
> It can be fixed by a Firmware upgrade, and more recently charges of Samsung SSD 980 PRO are flashed/sold with a good Firmware out-of-the-box.
While I am saying that my results with earlier Samsung have been less 
than glorious. triple layer nand's turning into half capacity for instance.
> 
> Best regards,
> 	Klaus.


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]

#275277

On Thu, Dec 05, 2024 at 07:32:03AM -0500, gene heskett wrote:
>While I am saying that my results with earlier Samsung have been less 
>than glorious. triple layer nand's turning into half capacity for 
>instance.

There's simply no real value in looking at historic bad models as a 
guide to future performance (or the opposite). I can remember entire 
lines of hard drives from reputable manufacturers which were plauged by 
premature failures to the point that I replaced some multiple times 
under warranty before pulling them all (e.g., the IBM Deskstar 75GXP). I 
can also remember SSDs which had problems with repeated file corruption 
(OCZ Vertex, the only SSDs I ever saw reliably corrupt stored data). 
Bottom line is that sometimes you'll get a dud, and it doesn't really 
matter if you had a positive (or negative) experience with a 
superficially similar product decades ago. The Samsung 980 pros with the 
bad firmware were a ticking time bomb, but they haven't been sold with 
that version for years, and they haven't had issues since the fix. Other 
Samsung SSDs have been fine. The 860s have relatively low write 
endurance, but that's why they're as cheap as they are. You can either 
avoid using them in write-intensive settings and get a drive advertised 
for that role, or you can dramtically underprovision to lower the write 
cycle of individual cells and create space for caching. That's true for 
most low-cost drives, which is why they're low-cost, and why 
high-write-cycle drives are fantastically expensive. The average 
consumer will never write enough data to matter, but it is possible in 
pathological cases if something on the system goes nuts and starts 
sync-writing a really large number of small blocks.

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

#275279

gene heskett wrote:
> On 12/5/24 06:59, Klaus Singvogel wrote:
> > 
> > It can be fixed by a Firmware upgrade, and more recently charges of Samsung SSD 980 PRO are flashed/sold with a good Firmware out-of-the-box.
> While I am saying that my results with earlier Samsung have been less than
> glorious. triple layer nand's turning into half capacity for instance.

In my memory, the PRO version of Samsung SSDs (not: NVMe) survived the test of a reputable website - many years ago. All other SSDs died when the article was written, except the Samsung PRO SSD. Their test continued.

But, on the other hand, the regular version (no PRO in the name) of the Samsung SSD died first in the test.

I think the data written to the Samsung SSD in the test exceeded twice the MTBF rate, several hundred TB.

But I also noticed that the quality of Samsung SSDs has adapted to the quality of their competitors (not in the good way). I read a lot about the 980 PRO and the Firmware debacle, but also heard that the 990 PRO shouldn't be any better.

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

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

#275311

On 12/5/24 08:55, Klaus Singvogel wrote:
> gene heskett wrote:
>> On 12/5/24 06:59, Klaus Singvogel wrote:
>>>
>>> It can be fixed by a Firmware upgrade, and more recently charges of Samsung SSD 980 PRO are flashed/sold with a good Firmware out-of-the-box.
>> While I am saying that my results with earlier Samsung have been less than
>> glorious. triple layer nand's turning into half capacity for instance.
> 
> In my memory, the PRO version of Samsung SSDs (not: NVMe) survived the test of a reputable website - many years ago. All other SSDs died when the article was written, except the Samsung PRO SSD. Their test continued.
> 
> But, on the other hand, the regular version (no PRO in the name) of the Samsung SSD died first in the test.
> 
> I think the data written to the Samsung SSD in the test exceeded twice the MTBF rate, several hundred TB.
> 
> But I also noticed that the quality of Samsung SSDs has adapted to the quality of their competitors (not in the good way). I read a lot about the 980 PRO and the Firmware debacle, but also heard that the 990 PRO shouldn't be any better.

The memory business is very competitive, so this doesn't surprise me. 
We've come a long way since the tv station I was working for pair $400 
for a 4 static memory to populate an 1802 based S100 board.  We call 
todays slap it together and get it out the door attitude the bblb 
syndrome. So my next experiment is to destry 
  
  
  

> 
> Best regards,
> 	Klaus.


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]

#275244

On Wed, Dec 4, 2024 at 11:07 AM Daniel Harris
<mail.dharris@googlemail.com> wrote:
>
> 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).

The drive should have a SMART interface. Does `smartctl -a` report any errors?

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

Jeff

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web