On Mon, 16 Jun 2025 10:34:42 +0000
Tomasz Torcz <tomek@???> wrote:
> On Sun, Jun 15, 2025 at 06:56:24PM +0200, Didier Kryn wrote:
> > Le 15/06/2025 à 17:57, Tomasz Torcz a écrit :
> > > On Sun, Jun 15, 2025 at 05:53:55PM +0200, Didier Kryn wrote:
> > > > Le 15/06/2025 à 17:52, Tomasz Torcz a écrit :
> > > > > > Wake up, reiserfs was removed from kernel in 6.13,
> > > > > > released last year.
> > > > > To be more precise, it was removed in October 2024, but
> > > > > 6.13 was released in January 2025.
> > > > And do you know for which reason?
> > > No-one to maintain it and keep up to date with changes in the
> > > kernel. Some discusssions at https://lwn.net/Articles/886582/
> > >
> > Apparently the problem is a kernel API change which breaks
> > backward compatibility.
> >
> > Very sad: I dislike do-it-all btrfs; zfs support on Linux is
> > tricky and led me to data loss. So fall back to ext4 which still has
> > the ext2 crap directory called lost+found which gets insanely
> > duplicated everywhere if you don't mind to take special care. Doesn't
> > look like progress. How happy were the reiserfs times!
>
> Why not XFS? It looks like most advanced, non-CoW, non-device-pool
> filesystem for Linux. With reflinks, online fsck, blocksizes>pagesize
> support it lacks nothing.
>
> Only disadvantage is that XFS has truncate-to-zero bug decades ago,
> and people still forgot it was fixed log ago.
To answer your question:
SGI XFS with ACLs, security attributes, realtime, verbose warnings,
quota, no debug enabled
XFS (loop0): Mounting V5 Filesystem 6738a12c-380a-45f3-ad94-4fe9ad9ba412
XFS (loop0): Ending clean mount
xfs filesystem being mounted at /media/ supports timestamps until
2038-01-19 (0x7fffffff)
xfs looks like it suffers from the 2038 bug.
And I agree that the removal of reiserfs was a poor choice. Alas, I'm in
no position to do anything about it.
David
::
Re: [DNG] Continued reiserfs suppor…
