1) Update journal's used_start in memory only after updating journal superblock.
Doing the opposite is incorrect because part of the journal will be lost if writers
overwrite its old beginning.
2) Sync journal device after updating the superblock.
3) Do not trim in rollback and init because trimming there would also require
updating the superblock. And the only reason to trim in both those places was
to unblock writers. And a guaranteed unblocking method will follow in the next
commit :)
This makes sense for some SSDs like Intel D3-4510 because they don't
like overwrites of the same sector:
$ fio -direct=1 -rw=write -bs=4k -size=4k -loops=100000 -iodepth=1
write: IOPS=3142, BW=12.3MiB/s (12.9MB/s)(97.9MiB/7977msec)
$ fio -direct=1 -rw=write -bs=4k -size=128k -loops=100000 -iodepth=1
write: IOPS=20.8k, BW=81.4MiB/s (85.3MB/s)(543MiB/6675msec)
The stall occurred during fio Q=128 random write tests with low flusher_count (4).
It was caused by flushers being unable to flush the beginning of the journal
because it contained older writes to an object that also had writes in the very end
of the journal, after dirty_start.
- Add support for benchmarking single primary OSD in fio_sec_osd
- Do not wait for the next event in flushers (return resume_0 back)
- Fix flushing of zero-length writes
- Print PG object count when peering
- Print journal free space when starting and when congested
It doesn't reduce actual WA, but it reduces tail latency (Q=32, 10% / 50% / 90% / 99% / 99.95%):
- write: 766us/979us/1090us/1303us/1729us vs 1074us/1450us/2212us/3261us/4113us
- sync: 701us/881us/1188us/1762us/2540us vs 269us/955us/1663us/2638us/4146us
Vitaliy Filippov