Data-on-MDT phase II
(LU-10176)
|
|
| Status: | Open |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Technical task | Priority: | Minor |
| Reporter: | Mikhail Pershin | Assignee: | WC Triage |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | DoM2, medium | ||
| Issue Links: |
|
||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||
| 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. |
| Comments |
| Comment by Andreas Dilger [ 25/Nov/17 ] |
|
I thought this was implemented or was in a patch somewhere already? |
| Comment by Joseph Gmitter (Inactive) [ 25/Sep/18 ] |
|
Mike, Is there still work to do here? Thanks. Joe |
| Comment by Mikhail Pershin [ 25/Sep/18 ] |
|
Joseph, yes, there are work to do. |
| Comment by Andreas Dilger [ 01/May/23 ] |
|
Patrick, is this something that would be easily done? |
| Comment by Patrick Farrell [ 01/May/23 ] |
|
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) |
| Comment by Andreas Dilger [ 01/May/23 ] |
|
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. |
[LU-10178]