Added a note about the callback functions

Added a short section about the callback functions, based on the answers
to issue #35 and #36

1 files changed, 12 insertions, 0 deletions

diff --git a/README.md b/README.md
index 9c06a26..a3b13b0 100644
--- a/README.md
+++ b/README.md
@@ -120,6 +120,18 @@ really do anything to ensure that the data written to disk is machine portable.
 This is fine as long as all of the involved machines share endianness
 (little-endian) and don't have strange padding requirements.
 
+In the configuration struct, the `prog` and `erase` function provided by the
+user may return a `LFS_ERR_CORRUPT` error if the implementation already can
+detect corrupt blocks. However, the wear leveling does not depend on the return
+code of these functions, instead all data is read back and checked for
+integrity.
+
+If your storage caches writes, make sure that the provided `sync` function
+flushes all the data to memory and ensures that the next read fetches the data
+from memory, otherwise data integrity can not be guaranteed. If the `write`
+function does not perform caching, and therefore each `read` or `write` call
+hits the memory, the `sync` function can simply return 0.
+
 ## Reference material
 
 [DESIGN.md](DESIGN.md) - DESIGN.md contains a fully detailed dive into how