Re: Orphaned Inode Problem

[Eike Lantzsch ZP5CGE / KY4PZ]

On Montag, 19. Februar 2024 14:20:52 -03 to...@tuxteam.de wrote:
> On Mon, Feb 19, 2024 at 10:02:10AM -0500, Stephen P. Molnar wrote:
> > I am running up to date Bookworm on my Debian platform:
> >
> > Processor   AMD FX(tm)-8320 Eight-Core Processor
> > Memory      8026MB (5267MB used)
> > Machine Type        Desktop
> > Operating System    Debian GNU/Linux 12 (bookworm)
> >
> > I have been plagued with orphaned inodes. Last night the problem
> > cane to a head. When I reboot the computer, after an orphaned inode
> > incident created stop, it got as far as the user login. After the
> > return I got the Windows infamous blue screen. Restarting produced
> > the same problem.
> >
> > Fortunately, I have another SSD used to test Bookworm, before
> > updating on the SSD that is having the problem. I can access the
> > problem drive and am in the process of backing up files.
> >
> > I ran sudo e2fsck -f/dev/sdc1 and got:
> >
> > Script started on 2024-02-19 08:15:52-05:00 [TERM="xterm-256color"
> > TTY="/dev/pts/0" COLUMNS="100" LINES="24"]
> > [?2004h(base) ]0;comp@AbNormal:
> > ~comp@AbNormal:~$ sudo e2fsck -f
> > /dev/sdc1lcaomosudo e2fsck -f
> > /dev/sdc1 [?2004l
> > [sudo] password for comp:
> > e2fsck 1.47.0 (5-Feb-2023)
> > Pass 1: Checking inodes, blocks, and sizes
> > Pass 2: Checking directory structure
> > Pass 3: Checking directory connectivity
> > /lost+found not found.  Create<y>? yes
> > Pass 4: Checking reference counts
> > Pass 5: Checking group summary information
> >
> > /dev/sdc1: ***** FILE SYSTEM WAS MODIFIED *****
> > /dev/sdc1: 7982363/121577472 files (0.3% non-contiguous),
> > 421959365/486307328 blocks
> > [?2004h(base) ]0;comp@AbNormal:
> > ~comp@AbNormal:~$ [?2004l
> >
> > Comments and suggestions will be appreciated.
>
> This session doesn't show anything to worry about. As far as fsck
> is concerned, the file system looks clean. Back up its contents as
> quickly as you can and treat the disk with suspicion. There are
> other candidate suspects for file system corruption (flaky power
> supply, software doing silly things, kernel bugs, loose cables),
> but the disk would be the pirmary.
>
> Cheers

Just as an aside note:
The notorious red SATA cables - I threw them out long ago. The red
pigment eats up the fine copper threads, changing the impedance of the
cable and eventually making false contact before failing completely.
Of course this does not apply to NVME SSDs.

--
Eike Lantzsch KY4PZ / ZP5CGE