mirror of
https://github.com/linux-apfs/apfstests.git
synced 2026-05-01 15:01:44 -07:00
91f87e3b89
test 284 had... some issues. First, it took so long nobody ran it; so shorten the extent count by a factor of about 100. Having fixed that, we see failures in 2 cases; when start or len is -1, but the golden output file didn't have error output, as if they should pass. I'm going to argue that these *should* both fail; start = -1 has no real meaning. length = -1 might mean "the rest of the file" but if that's what you really want, just don't specify -l. So add failure output for those cases. Send all command output to $seq.full, in case that changes in the future; just capture the return value. Then remove the return value echo on failure (50?) because who knows when that might change to some other magic value. Ok, then when defrag actually works, old defrag returned "20" (because?) but a recent commit changed it to 0. So accommodate that too. And remove a stray "HAVE_DEFRAG=1" while we're at it. That variable is never used. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Josef Bacik <jbacik@fusionio.com> Reviewed-by: Liu Bo <bo.li.liu@oracle.com> Signed-off-by: Rich Johnston <rjohnston@sgi.com>
14 lines
564 B
Plaintext
14 lines
564 B
Plaintext
QA output created by 284
|
|
defrag object | defragment range | defragment compress
|
|
a single file | default | off
|
|
a single file | default | on
|
|
a single file | start < 0 && 0 < len < file size | off (should fail)
|
|
btrfs filesystem defragment failed!
|
|
a single file | start > file size && 0 < len < file size | off
|
|
a single file | start = 0 && len < 0 | off (should fail)
|
|
btrfs filesystem defragment failed!
|
|
a single file | start = 0 && len > file size | off
|
|
a single file | start = 0 && 0 < len < file size | off
|
|
a directory | default | off
|
|
a filesystem | default | off
|