On 2023/6/21 13:47, Anand Jain wrote:
+for i in $SCRATCH_DEV_POOL; do
+ devsize=$(blockdev --getsize64 "$i")
+ if [ $devsize -lt $((2 * 1024 * 1024 * 1024)) ]; then
+ _notrun "device $i is too small, need at least 2G"
Also, you need to check if those devices support discard.
Uneven device sizes will alter the distribution of chunk allocation.
Since the default chunk allocation is also based on the device sizes
and free spaces.
That is not a big deal, if we have all 6 devices beyond 2G size, we're
already allocating the device stripe in 1G size anyway, and we're
ensured to have a 6G RAID0 chunk no matter if the sizes are uneven.
It's the next new data chunk going to be affected, but our workload
would only need the initial RAID0 chunk, thus it's totally fine to have
uneven disk sizes.
+ fi
+done
+
+_scratch_pool_mkfs -m raid1 -d raid0 >> $seqres.full 2>&1
+_scratch_mount
+
+# Fill the data chunk with 5G data.
+for (( i = 0; i < $nr_files; i++ )); do
+ xfs_io -f -c "pwrite -i /dev/urandom 0 $filesize"
$SCRATCH_MNT/file_$i > /dev/null
+done
+sync
+echo "=== With initial 5G data written ===" >> $seqres.full
+$BTRFS_UTIL_PROG filesystem df $SCRATCH_MNT >> $seqres.full
+
+_scratch_unmount
+
+# Make sure we haven't corrupted anything.
+$BTRFS_UTIL_PROG check --check-data-csum $SCRATCH_DEV >> $seqres.full
2>&1
+if [ $? -ne 0 ]; then
+ _fail "data corruption detected after initial data filling"
+fi
+
+_scratch_mount
+# Delete half of the data, and do discard
+rm -rf - "$SCRATCH_MNT/*[02468]"
Are there any specific chunks that need to be deleted to successfully
reproduce this test case?
No, there is and will only be one data chunk.
We're here only to create holes to cause extra trim workload.
+sync
+$FSTRIM_PROG $SCRATCH_MNT
Do we need fstrim if we use mount -o discard=sync instead?
There is not much difference.
Thanks,
Qu
Thanks, Anand
