refactor: configure storage benchmark to use sequential writes

[jim-junior]

This is to PR updates the fio workload to use sequential writes instead of random read and writes by changing the --rw flag from randrw to write.

Goal for this PR was because , gVisor's user-space Sentry handled random lookups quickly inside RAM rather than hitting the true storage stack. This created an architectural illusion of blisteringly fast speeds that didn't reflect actual runtime constraints. A sustained sequential write forces gVisor to continuously serialize and flush data over its internal Gofer communication ring to the host system. This breaks the in-memory shortcut, bringing the numbers back down to earth and exposing the true, expected system-call interception overhead.

Furthermore the workload image has been changed from the standard ubuntu based fio image to xridge/fio. an alpine based image and widely used.

Results from an experiment of 20 repeated runs per runtime below.

Runtime	Median BW	Run-to-run CV	Typical mean clat	Stability
urunc	~509 MiB/s	~1.4%	~6.6 µs	Excellent
runc	~284 MiB/s*	~25%	~6–8 µs normal runs	Poor
runsc	~227 MiB/s	~0.5%	~16.6 µs	Excellent
Kata	~47.5 MiB/s	~7.7%	~79 µs	Reasonable

Important

In the repeated runs there was some variation in the runtime results accross runs, most especially for runc however I have included the Run-to-run CV in the table to show how variance in results.

script used to test this was:

for i in {1..20}; do
    echo "===== RUN $i ====="

    sudo sync

    grep -E 'Dirty|Writeback' /proc/meminfo

    sudo nerdctl run --rm \
      --runtime=io.containerd.runc.v2 \ #we replaced this with approprate runtime shim
      xridge/fio \
      --name=test \
      --rw=write \
      --bs=4k \
      --size=256M \
      --iodepth=1 \
      --runtime=30 \
      --time_based

    sleep 10
done