Technical task
Minor Description
While processing CLIO fsync IO an OSC sends separate SYNC request when BRW is finished. The optimization idea is to avoid this just by making last BRW synchronous instead. Refer to the osc_io_fsync_start(), osc_fsync_ost() functions and mdc_io_fsync_start() as well.
Attachments
Activity
The goal here would be to send the last RPC without OBD_BRW_ASYNC if there is data to be flushed, so that it forces a sync and returns with an updated transno. This would be most useful for flushing small files, where it would cut the RPC count in half.
Nothing urgent, just an open ticket that I found that seems like it would be easily fixed.
Hmm, I'm only about 80% sure I understand. It sounds like we're saying when there's data to flush on an fsync, we should just make the RPC sync, so it forces the OST to do a sync, rather than send a separate sync request to the OST.
It wouldn't be the hardest thing in the world; we'd modify how FSYNC works a little so it would force data written out to be synchronous. The harder part would be making sure we tracked if sync actually sent anything, but it wouldn't be that hard.
Is fsync expected to force a journal commit? It is, right? So we for sure have to send a sync command to the OST, whether or not we have any dirty data to sync. It's just that if we have dirty data we are sync'ing, we could skip the separate sync request.
May I ask why this is of interest? It seems a pretty small optimization for a case that I don't normally think of as really performance sensitive? (I'm happy to learn here, that's why I'm asking)
I thought this was implemented or was in a patch somewhere already?
Oh, jeez, it's been a hot second here - But I understand now, and I additionally now understand that any sync RPC will sync the journal as well. I recognize that misunderstanding in my previous reply.