Flush after writing to file and dma alignment

[Hải Nguyễn]

Hi all,

I would like to persist something to file system, then writing something else after that point, just like splitting a large big into several chunks and write + flush every chunk.

Running that kind of code cause assertion because of dma alignment (4096 bytes). Of course the release build does not has that kind of assertion.

I would like to ask is there any mechanism to write and flush buffer data into file, then continue to write into that file?

Thank you,

Hai.

[Avi Kivity]

As long as you write aligned chunks, what you say should work. If it doesn't, that's a bug.

Writing an unaligned chunk is currently only supported at the end of a file (and would be quite hard to change).

--
You received this message because you are subscribed to the Google Groups "seastar-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seastar-dev...@googlegroups.com.
To post to this group, send email to seast...@googlegroups.com.
Visit this group at https://groups.google.com/group/seastar-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/seastar-dev/cd44fef5-1258-4c95-9164-3673ce1f326c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Hải Nguyễn]

Thank Avi. How about writing commit log in Scylla? Saying user would like to write a key of 100 bytes for example, the data would be persisted in commit log, right?
How that persistence could be done, if the data to write is unaligned?

Certainly, we can group a number of keys to make it aligned, say grouping 40 keys together to make one aligned write. What if during waiting for incoming keys from user, the server get power outage and the already-received keys but haven't written yet are gone. This is unacceptable from commit log terminology.

Hai.

[Avi Kivity]

The commit log aligns writes to 4k. The format explicitly allows for padding.

The usual technique is to batch. When the first write arrives, you write it to disk. While waiting for the disk to complete the write, you accumulate further incoming writes. When the disk responds, you send all accumulated writes in one disk operation, and start accumulating a new batch.

To view this discussion on the web visit https://groups.google.com/d/msgid/seastar-dev/b1189d7e-42d2-4ee7-bd0e-fe16e7fb27b6%40googlegroups.com.

[Hải Nguyễn]

Thank you Avi. I tried play several days with alignment, found that the batching technique is the most appropriate so far. Hope in the near future, seastar will support unaligned write and flush.

[Avi Kivity]

Unaligned write cannot be supported efficiently, because the underlying hardware doesn't. An unaligned write would be translated to a read-modify-write (if we don't cache the last block) or to an overwrite (if we do). Both are problematic.

For commit logs, it is much better to pad than to save a bit of space. With batching, the wasted space is minimal.

To view this discussion on the web visit https://groups.google.com/d/msgid/seastar-dev/92cac557-b078-40f9-8b1a-bfd64afe9036%40googlegroups.com.