The attribute fallback for an object that is not on Lustre uses a stat, which
cannot report a birth time or the statx attribute flags. So a record gathered
outside Lustre leaves LLAPI_SCAN_BTIME and LLAPI_SCAN_ATTRS
clear, and lfs find -btime matches nothing there. Fetching with statx()
would answer both on a filesystem that has them, such as ext4 or XFS.

This is an enhancement and not a defect, for two reasons worth recording so
that it is not filed twice as a bug.

The High Level Design does not require it. It suggests statx as a likely
implementation route for the POSIX Input Scanner, in a sentence whose
requirement is that the module be built inside the namespace scanner rather
than duplicated. The module itself sits outside the three initial Input
Scanners the design names. A birth time is not in the standard attribute list
it asks for, which is size, blocks, atime, mtime and ctime. And it states that
attributes should be returned if readily available and omitted if not, which is
what the validity mask already does.

The behaviour is also already deliberate and is not specific to POSIX. An
object with no birth time does not match a birth time test, and the search
carries on rather than failing, because failing after matches have been printed
is the wrong answer and on a walk the error would take the whole subtree with
it. An old ldiskfs inode whose i_extra_isize does not
reach i_crtime has no birth time either and behaves the same way on Lustre. Fetching with
statx would fix that for the POSIX case and leave the ldiskfs case as it is, so
it moves the boundary rather than removing it.