When attempting to install fdb 5.1.7 on a newly installed win10 machine, we got this weird error:
<Event Severity="40" Time="1528381129.831068" Type="FileOpenError" Machine="127.0.0.1:4500" ID="0000000000000000" Reason="Must be unbuffered" Flags="131074" File="C:\ProgramData\foundationdb\data\4500\storage-811f51d3f2dd5414739706e38748a17b-0.fdq" logGroup="default" Backtrace=""/> <Event Severity="40" Time="1528381129.831068" Type="DiskQueueShutdownError" Machine="127.0.0.1:4500" ID="811f51d3f2dd5414" Reason="unknown" Error="io_error" ErrorDescription="Disk i/o operation failed" ErrorCode="1510" logGroup="default" Backtrace=""/>
This is right after installing via the setup (that pre-configures the db using the memory storage engine).
When connecting to fdbcli, the cluster was unavailable. Attemtping to “configure single ssd” did not seem to work at first. Then after restarting everything, it now works fine, and it is using the ssd-2 storage engine. The last logged error for the node is
I think that for some reason, the memory engine did try to open a file on windows without specifying the
OPEN_UNBUFFERED that is tested in
AsyncFileWinASIO::open(..) but I have difficulty, looking at the code, to find why.
After the restart, my guess is that the storage was successfully converted from memory to ssd-2 and the error went away.
The file name in the error is
xxxx-0.fdq which seems to be only used by the Memory engine, so maybe only this path may forget to set the flag OPEN_UNBUFFERED in some cases?
AsyncFileKAIO::open() for linux seem to check the flag via
ASSERT( flags & OPEN_UNBUFFERED ); while the Widows version is more explicit in tracing and throwing an error… maybe there is difference in behavior there?