On 2026-05-01, c186282 <c186282@nnada.net> wrote:

On 4/30/26 20:15, Lawrence D?Oliveiro wrote:

On Thu, 30 Apr 2026 12:36:59 -0000 (UTC), Borax Man wrote:

I find it amusing that there are people who would still do that.

fsck, you mean? It?s not something I do routinely, only if/when I have
to.

Well ... can't really hurt ......

Mystery problems CAN arise almost invisibly.

Indeed. I found I had bad RAM while trying to copy files from my
computer to another. Was using btrfs-send, and it kept failing at
random spots. At first I thought it was bad files, but after restoring
the affected files from a backup, other random files were affected. It
seemed no matter what I did, more were going corrupt. Bad hard drive?
Bad hard drive controller? But why specific files?

After running memtest, it quickly found the issue.

I dont think ext4.fsck picked anything up.

btrfs gets a lot of crap, but thats the second time it has made me aware
of hardware issues that were leading to bad data.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-04-30, Kenny McCormack <gazelle@shell.xmission.com> wrote:

In article <slrn10v6j7b.acg.rotflol2@geidiprime.bvh>,
Borax Man <rotflol2@hotmail.com> wrote:
...

The time it would take to backup-format-reinstall would, I think,
greatly exceed the time saved waiting for that FSCK to complete the few >>times a year you might needs to FSCK it.

I find it amusing that there are people who would still do that.

I get what you are saying, and it is no doubt correct, but I also
understand the feeling that I think we've all experienced at several points in our time with computers. The feeling that something just isn't right; that is is not quite kosher and will probably develop other problems as
time goes by. And that starting over - reformatting/whatever - is a good thing to do, to get things back to pristine.

And it does look, based on this thread, that a disk partition (filesystem) converted from EXT3 to EXT4 (without being reformatted, etc) is not quite a real/kosher EXT4 filesystem. And thus that re-doing it from scratch might
be a good idea.

A lot of it is in your head. When I converted I just took it for
granted the conversion was done, and I didn't know how much faster FSCK
could be until I formatted another disk fresh. The ignorance (if you
could call it that), made me think in my head, it was all good.

After a while, you forget about it all.

But I'm of this "if it aint broke, don't fix it" mentality. I've had
Linux installations run for years, filesystems run for years, and
generally its never been a problem. Its the hardware that is "not quite
right" which gets me.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-04-30, Nuno Silva <nunojsilva@invalid.invalid> wrote:

On 2026-04-30, Kenny McCormack wrote:

In article <slrn10v6j7b.acg.rotflol2@geidiprime.bvh>,
Borax Man <rotflol2@hotmail.com> wrote:
...

The time it would take to backup-format-reinstall would, I think,
greatly exceed the time saved waiting for that FSCK to complete the few >>>times a year you might needs to FSCK it.

I find it amusing that there are people who would still do that.

I get what you are saying, and it is no doubt correct, but I also
understand the feeling that I think we've all experienced at several points >> in our time with computers. The feeling that something just isn't right;
that is is not quite kosher and will probably develop other problems as
time goes by. And that starting over - reformatting/whatever - is a good
thing to do, to get things back to pristine.

And it does look, based on this thread, that a disk partition (filesystem) >> converted from EXT3 to EXT4 (without being reformatted, etc) is not quite a >> real/kosher EXT4 filesystem. And thus that re-doing it from scratch might >> be a good idea.

I'd guess there's probably a lot of room for variability between the placement of things and default options in a brand-new ext4 filesystem
and what is a valid ext filesystem (even if suboptimal). Does the
conversion try to get it close to e.g. the current defaults for mkfs, or
does it merely upgrade as little as possible to make it ext4-compatible?

It just does some metadata updates. The files themselves are not
re-written. You are basically enabling new features, but leaving pretty
much all the file metadata, and the file structure as-is. That why the conversion is really just enabling some flags.

What it does mean is that files which would have been written using
extents, still don't use them, and the timestamps aren't to the
millisecond. Unused block groups which could be skipped during fsck are
still marked as they were.

EXT4 isn't fundamentally different to EXT3 in terms of disk-layout, and
EXT3 was just EXT2 with a journal.

Come to think of it, its quite late in the game to be still running
EXT3! EXT4 is already nearly two decades old. Personally, I'd
recommend BTRFS or XFS, especially for large storage/archival.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-03 14:29, Borax Man wrote:

Come to think of it, its quite late in the game to be still running
EXT3! EXT4 is already nearly two decades old. Personally, I'd
recommend BTRFS or XFS, especially for large storage/archival.

I don't trust btrfs, and xfs poses problems when used for root; for data
it is perfect.

I have a raid 6 with 8 active disks, LUKS encrypted and using btrfs with compression. It has developed an error, impossible to correct (I don't
know how, got advice about what to do, but took days and it aborted. Eventually will redo with XFS instead).

--
Cheers, Carlos.
ES??, EU??;

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sun, 3 May 2026 21:13:50 +0200, Carlos E.R. wrote:

I don't trust btrfs ...

Fun fact, Oracle includes btrfs with its ?Unbreakable? Linux.

You know, this is the company that owns ZFS, which some people swear
by. But it won?t offer that with its own Linux distro. Vote of
confidence in your own technology, much?

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)