All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Baokun Li <libaokun@linux.alibaba.com>
Cc: Theodore Tso <tytso@mit.edu>,
	fstests@vger.kernel.org, zlang@kernel.org,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	sandeen@redhat.com, dgc@kernel.org
Subject: Re: [PATCH] generic/492: bypass the blkid cache when probing the label
Date: Tue, 22 Sep 2026 07:53:35 -0700	[thread overview]
Message-ID: <20260922145335.GV6283@frogsfrogsfrogs> (raw)
In-Reply-To: <74463cb5-14af-47bb-9380-ca75dc5d293a@linux.alibaba.com>

On Tue, Sep 22, 2026 at 03:17:27PM +0800, Baokun Li wrote:
> On 2026/9/22 11:43, Theodore Tso wrote:
> > On Mon, Sep 21, 2026 at 04:49:10PM -0500, Darrick J. Wong wrote:
> >>> The difference between the e2fsprogs and util-linux libblkid is the
> >>> time granularity: the former stores seconds only (TIME="%ld",
> >>> bid_time = time(0), compares st_mtime <= bid_time), while the latter
> >>> stores usec (TIME="sec.usec") and has an nsec tie-break in the compare,
> >>> so the same-second case is much easier to hit with the e2fsprogs blkid.
> >> Perhaps xfstests-bld should use the system blkid then?  IIRC the one
> >> in e2fsprogs is very old and out of date.
> > Historically, xfstests-bld was built in environments where libblkid
> > wasn't available.  This included Android's runtime (which uses the
> > bionic libc), and grte (Google Runtime Environment)[1].
> >
> > [1] https://github.com/bazelment/lrte/blob/master/grte/grte-build
> >
> > However, as more and more tests require utilities from util-linux,
> > xfstests-bld was taught to build util-linux.  And if util-linux is
> > being built, then we don't use e2fsprogs-libs any more, which is where
> > libblkid is built.  From build-all:
> >
> > if test -z "$USE_LOCAL_E2FSLIBS" -o -d util-linux; then
> >     SKIP_E2FSLIBS=yes
> > fi
> >
> > I've always built xfstesets-bld with util-linux, even though it is
> > listed as an optional repository.  This is because (a) util-linux is
> > needed for Android and other non-standard Linux environments, and (b)
> > the version of util-linux used by earlier Debian Stable was too old
> > for some of the newer tests in fstests and blktests.
> >
> > If you aren't building xfstests-bld with util-linux, it falls back to
> > building libblkid from e2fsprogs-libs.  HOWEVER, we don't actually
> > blkid, and libblkid is always built statically.  So what seems to be
> > going on is that one of the programs built by xfstests-bld is using
> > the older libblkid, and that results in the blkid cache being writen
> > with a second granularity.
> >
> > I've never noticed this issue because I've always built with
> > util-linux.  The way to solve this is to require building with the
> > system libblkid if util-linux is not being built, and to drop
> > e2fsprogs-libs from xfstests-bld.  Or just build xfstests-bld with
> > util-linux.  :-)
> 
> 
> Thanks for the detailed explanation.
> 
> I checked my environment again though -- it turned out not to be
> xfstests-bld at all.  xfstests-bld never touches e2fsprogs.
> 
> What happened is that I had manually run "make install" of a locally
> patched e2fsprogs in the test VM, which overwrote util-linux's blkid
> and fsck.
> 
> Rebuilding e2fsprogs with these options disabled made the test pass:
> 
>     ./configure --disable-libblkid --disable-fsck \
>             --disable-libuuid --disable-uuidd
> 
> I ran unpatched generic/492 60 times on each side in a VM: 12/60
> failures with the hand-installed strays, 0/60 with util-linux's
> blkid/fsck.
> 
> That said, I think the patch is still needed, because
> FS_IOC_SETFSLABEL does not update the block device's mtime:

Many filesystems /never/ update the bdev mtime, why would they?

>     blkid -s LABEL ...    # get A
>     FS_IOC_SETFSLABEL     # set B (device mtime unchanged)
>     blkid -s LABEL ...    # still get A (within 2s)
> 
> The first read writes a cache entry with TIME=now, and the ioctl
> leaves the device mtime untouched, so a second read within the 2s
> window still trusts the cache.
> 
> I reproduced this with util-linux 2.41.5 too, so
> "blkid -c /dev/null" is what keeps the test deterministic
> regardless of which blkid the image carries.

<nod> That was the problem I thought you were solving here ;)

--D

> 
> Cheers,
> Baokun
> 
> 

  reply	other threads:[~2026-09-22 14:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-20  9:41 [PATCH] generic/492: bypass the blkid cache when probing the label Baokun Li
2026-09-21  5:27 ` Darrick J. Wong
2026-09-21  9:07   ` Baokun Li
2026-09-21 23:49     ` Darrick J. Wong
2026-09-22  3:43       ` Theodore Tso
2026-09-22  7:17         ` Baokun Li
2026-09-22 14:53           ` Darrick J. Wong [this message]
2026-09-23  9:13             ` Baokun Li
2026-09-22 15:56           ` Theodore Tso
2026-09-23 10:02             ` Baokun Li
2026-09-24  2:25               ` Theodore Tso
2026-09-24  8:09                 ` Baokun Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260922145335.GV6283@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=dgc@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=libaokun@linux.alibaba.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=tytso@mit.edu \
    --cc=zlang@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.