Re: [PATCH v2 0/7] large atomic writes for xfs

John Garry
2024-12-16T08:40:49Z

>>
>> Yeah, at the low end, it may make sense to do the 512B write via DIO. But
>> OTOH sync'ing many redo log FS blocks at once at the high end can be more
>> efficient.
>>
>> From what I have heard, this was attempted before (using DIO) by some
>> vendor, but did not come to much.
>>
>> So it seems that we are stuck with this redo log limitation.
>>
>> Let me know if you have any other ideas to avoid large atomic writes...
>
> From the description it sounds like the redo log consists of 512b blocks
> that describe small changes to the 16k table file pages. If they're
> issuing 16k atomic writes to get each of those 512b redo log records to
> disk it's no wonder that cranks up the overhead substantially.

They are not issuing the redo log atomically. They do 512B buffered
writes and then periodically fsync.

> Also,
> replaying those tiny updates through the pagecache beats issuing a bunch
> of tiny nonlocalized writes.
>
> For the first case I don't know why they need atomic writes -- 512b redo
> log records can't be torn because they're single-sector writes. The
> second case might be better done with exchange-range.
>

As for exchange-range, that would very much pre-date any MySQL port.
Furthermore, I can't imagine that exchange-range support is portable to
other FSes, which is probably quite important. Anyway, they are not
issuing the redo log atomically, so I don't know if mentioning
exchange-range is relevant.

Regardless of what MySQL is specifically doing here, there are going to
be other users/applications which want to keep a 4K FS blocksize and do
larger atomic writes.

Thanks,
John