test: add test case 'TestResetAfterWrite' #520
Conversation
Signed-off-by: Benjamin Wang <[email protected]>
| } | ||
|
|
||
| tmpBuf := make([]byte, 4096) | ||
| if n, err = f.ReadAt(tmpBuf, 0); err != nil { |
There was a problem hiding this comment.
do you think that f.writeAt doesn't actually persist the data and zeroing the page after will actually cause an empty page to be written?
sounds like a specific network file system again ;-)
There was a problem hiding this comment.
Yes, that's my guess. In theory it's possible. But usually it's unlikely because there is a datasync by default before resetting the buf.
If it happens, then it means that:
- the datasync is disabled by users or it did NOT work;
- and the buf was reset before the writeAt really copied the data from the buf
There was a problem hiding this comment.
I think it's not possible because WriteAt is sync call which uses pwrite syscall under Linux. Before function returns, it copies user provided buffer into OS buffer. So, resetting the buffer does not have any effect after WriteAt returns.
There was a problem hiding this comment.
Plus it doesn't matter whether fsync is called or not. OS always looks at page cache first when reading.
There was a problem hiding this comment.
On "normal" filesystems you have the read after pwrite guarantee, yes. Hence my stab at NFS earlier. I think it's difficult to repro this without a clearer picture on the hardware/OS setup for this test.
There are a couple of data corruption cases, in which some pages are reset; In other words, all data in the pages are zero values. I am not sure whether it has anything to do with code below on some platform (e.g. windows),
bbolt/tx.go
Lines 489 to 491 in b31e3ec
Anyway, added case
TestResetAfterWriteto double check.cc @ptabor @cenkalti @tjungblu