Since a few days the CI started to fail randomly when there were loop
devices used in the tests. The mount fails because some device is
reported to be missing:
$ losetup --show --find
/dev/loop3
...
$ mkfs ...
ERROR: device scan failed on '/dev/loop3': No such file or directory
...
$ mount
mount: /home/runner/work/btrfs-progs/btrfs-progs/tests/mnt: wrong fs
type, bad option, bad superblock on /dev/loop3, missing codepage or
helper program, or other error.
$ dmesg
...
BTRFS error (device loop0): devid 3 uuid 11d9c345-9527-433e-a024-7102659fa0ee is missing
BTRFS error (device loop0): failed to read the system array: -2
BTRFS error (device loop0): open_ctree failed
This was reproducible in the "cli" tests, but also happened on a local
machine.
To fix that wait for all loop devices before mount, the command
'btrfs device ready' should block until that. The convenience helper
does that, for any standalone 'mount' used with loop devices this must
be done manually.
Signed-off-by: David Sterba <dsterba@suse.com>
The new test case would:
- Prepare two loopback devices
One is for storing the source directory (on a btrfs).
This is to ensure we can set xattr for the directory, as filesystems
like tmpfs (mostly utilized by mktemp) is not supporting xattr.
The other one is the real target fs where we call
"mkfs.btrfs --rootdir" on.
- Create the source directory with the following contents:
* rootdir inode attributs:
# mode (750)
# uid (1000)
# gid (1000)
# xattr (user.rootdir)
* one regular file, with attributes:
# xattr (user.foorbar)
- Execute "mkfs.btrfs --rootdir" and mount the new fs
- Verify the above attributes
The target fs should have the same attributes, especially for the
rootdir inode.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>