Message-ID: <20250613020412.GA5819@mit.edu>
Date: Thu, 12 Jun 2025 23:34:12 -0230
From: "Theodore Ts'o" <tytso@....edu>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: linux-ext4@...r.kernel.org
Subject: Re: [PATCH 3/3] fuse2fs: catch positive errnos coming from libext2fs

On Thu, Jun 12, 2025 at 03:15:52PM -0700, Darrick J. Wong wrote:
> 
> I.... had no idea that errcode_t's were actually segmented numbers.  Is
> there a way to figure out the subsystem from one of them?

Sure, you can take the high 24-bits, and group them into 4 chunks of
6-bit numbers, and then apply the lookup table found in
lib/et/et_c.awk:

## "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_";
c2n["A"]=1
c2n["B"]=2
c2n["C"]=3
 ...
c2n["7"]=60
c2n["8"]=61
c2n["9"]=62
c2n["_"]=63

> Or will fuse2fs just have to "know" that !(errcode & 0xFFFFFF00)
> means "errno"?

How error codes get translated into strings is implemented by
lib/et/error_message.c.  If the high 24-bits are zero, then
error_message.c will call strerror(code), because it's assumed that
it's an errno.

Fuse2fs's __translate_error() function is also trying to interpret
error codes, and normally, most code paths just either (a) call
error_message(code) or (b) compare the code for equality against a
specific code point.  But __translate_error() needs to know the
internal underlying structure of the error code so it can do its own
translation, so it has to peer behimd the abstraction barrier
implemented by the com_err library.

I'll note that this scheme is a little fragile, because POSIX does not
guarantee that errno's have to be small integers that fit in the low 8
bits of an integer.  In practice this is true, but there is nothing
stopping a confirming POSIX implementation of some OS to use, say, to
have errnos between 0 and 1024.  Or perhaps some OS might try to
implement their own segmented error code space for errno's.  But in
practice, this has worked out for all the various subsystems that use
the com_err infrastructure, and like libext2fs, the krb5 library has
been ported to zillions of environments.

> Hrm -- if MMP fails, that implies that we might not be the owner of
> this filesystem, right?  Doesn't that means we should be careful about
> not scribbling on the superblock?

Well, the only time we check against MMP is when the file system is
opened.  That's because e2fsprogs doesn't implemented the full MMP
protocol as is found in the kernel.  In order to do that, we'd have to
spawn a separate thread which is periodically checking the superblock
to make sure no other node on the shared block file system has tried
to modify the file system out from under us.

Since historically e2fsprogs is single-threaded, what we do instead is
we write a magic value into the MMP sequence number,
EXT4_MMP_SEQ_FSCK, and if you are unfortunate enough to crash while
fsck.ext4 (or fuse2fs or other e2fsprogs program) is operating on a
file system, then a system adminsitrator would have to recover the
system manually using debugfs -c ("catastrophic recovery" mode) and
its set_super_value command to manually clear the MMP fields.

If we really care about trying to use fuse2fs in a primary/secondary
failover setup using a shared block device, we probably should put a
first class MMP implementation into libext2fs if threading is enabled.
However, the use of MMP is rare enough that it's probably not a high
priority to implement, at least not immediately.

					- Ted

Powered by blists - more mailing lists