bonnie++-1.03e Direct I/O Compiler Errors

bonnie++ is the simplest tool that can validate if the disks in a server are working at expected speed. It’s not always accurate, and some of its tests are meaningless nowadays. But the sequential read and write rate figures it computes are usually right for smaller servers, and it automates details like sizing the test file to exceed RAM caching. The main thing to watch out for is that large servers with many disks (or very fast SSDs) may max out the CPU bonnie++ is running on before the true maximum rate is found. bonnie++ has been split into a stable 1.0 and a development 2.0 version for a while; the 2.0 branch allows using more CPUs to improve on that issue. I still see enough quirkiness in the new branch that I settle for the 1.0 series on any server without fast storage.

Except today, when I was trying to get bonnie++-1.03e running on a Mac laptop. The latest update to the program added support for Direct I/O. That looks like it was tested on Linux, and it works fine on some systems. But on many types of BSD UNIX derived systems, including Mac OS X, NetBSD, and Solaris, bonnie++-1.03e won’t compile. You get this error instead:

$ make
g++ -O2  -DNDEBUG -Wall -W -Wshadow -Wpointer-arith -Wwrite-strings -pedantic -ffor-scope   -c bon_io.cpp
bon_io.cpp: In member function ‘int CFileOp::m_open(const char*, int, bool)’:
bon_io.cpp:398: error: ‘O_DIRECT’ was not declared in this scope
make: *** [bon_io.o] Error 1

There are two worksarounds for this problem. The easier one is to roll back to version 1.03d. The only thing added by 1.03e is the Direct I/O feature that doesn’t compile.

Since this sort of thing ticks me off, I wanted to fix it in a way I can roll forward into newer versions too. NetBSD packaging added a commit to fix the problem by Jaromir Dolecek. The relevant code is in patch 1 and patch 2. Since the fixes are so small, I combined them both into a single git created context dif, and it’s easier to paste it here than store it somewhere:

diff --git a/bon_io.cpp b/bon_io.cpp
new file mode 100644
index a9eab20..ac8d6e6
*** a/bon_io.cpp
--- b/bon_io.cpp
*************** CFileOp::CFileOp(BonTimer &timer, int fi
*** 318,324 ****
--- 318,326 ----
   , m_isopen(false)
   , m_name(NULL)
   , m_sync(use_sync)
+ #ifdef O_DIRECT
   , m_use_direct_io(use_direct_io)
+ #endif
   , m_chunk_bits(chunk_bits)
   , m_chunk_size(1 << m_chunk_bits)
   , m_chunks_per_file(Unit / m_chunk_size * IOFileSize)
*************** int CFileOp::m_open(CPCCHAR base_name, i
*** 393,403 ****
--- 395,407 ----
      flags = O_RDWR | O_CREAT | O_EXCL;
+ #ifdef O_DIRECT
        flags |= O_DIRECT;
+ #endif
diff --git a/bon_io.h b/bon_io.h
new file mode 100644
index cbce2b1..3772140
*** a/bon_io.h
--- b/bon_io.h
*************** private:
*** 33,39 ****
--- 33,41 ----
    bool m_isopen;
    char *m_name;
    bool m_sync;
+ #ifdef O_DIRECT
    bool m_use_direct_io;
+ #endif
    const int m_chunk_bits, m_chunk_size;
    int m_chunks_per_file, m_total_chunks;
    int m_last_file_chunks;

Apply that patch, and 1.03e will compile on my Mac. I don't really need the 1.03e features yet, but one day there might be something in a later 1.03f or 1.04 I do want. Then it will be nice to have a patch to fix the problem like this one.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>