Addition of fs-specific timestamp range checking was added
in
188d20bcd1eb ("vfs: Add file timestamp range support").
Add a check for whether the kernel supports the limits check
before running the associated test.
Based on an off-list discussion, we use a simpler interim approach
until fsinfo syscall would provide fs timestamp limits info.
This isn't perfect, but works for filesystems expiring in 2038.
Suggested-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
if [ $tsmin -eq -1 -a $tsmax -eq -1 ]; then
_notrun "filesystem $FSTYP timestamp bounds are unknown"
fi
+
+ # expect console warning from rw scratch mount if fs limit is near
+ if [ $tsmax -le $((1<<31)) ] && \
+ ! _check_dmesg_for "filesystem being mounted at .* supports timestamps until"
+ then
+ _notrun "Kernel does not support timestamp limits"
+ fi
}
_filesystem_timestamp_range()
here=`pwd`
tmp=/tmp/$$
status=1 # failure is the default!
-trap "exit \$status" 0 1 2 3 15
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+_cleanup()
+{
+ cd /
+ rm -f $tmp.*
+}
# Get standard environment, filters and checks.
. ./common/rc
_supported_fs generic
_supported_os Linux
_require_scratch
+_require_check_dmesg
_require_xfs_io_command utimes
# Compare file timestamps obtained from stat
}
_scratch_mkfs &>> $seqres.full 2>&1 || _fail "mkfs failed"
+_scratch_mount || _fail "scratch mount failed"
+
_require_timestamp_range $SCRATCH_DEV
read tsmin tsmax <<<$(_filesystem_timestamp_range $SCRATCH_DEV)
$((tsmax+1))
)
-_scratch_mount || _fail "scratch mount failed"
-
status=0
# Begin test case 1