On Mar 19, 2013, Chris Mason <clmason@xxxxxxxxxxxx> wrote: > My guess is the truncate is creating a orphan item Would it, even though the truncate is used to grow rather than to shrink the file? > that is being processed inside the snapshot. This doesn't explain why the master database occasionally gets similarly corrupted, does it? > Is it possible to create a smaller leveldb unit test that we might use > to exercise all of this? I suppose we can even do away with leveldb altogether, using only a PosixMmapFile object, as created by PosixEnv::NewWritableFile (all of this is defined in leveldb's util/env_posix.cc), to exercise the creation and growth of multiple files, one at a time, taking btrfs snapshots at random in between the writes. This ought to suffice. One thing I'm yet to check is whether ceph uses the sync leveldb WriteOption, to determine whether or not to call the file object's Sync member function in the test; this would bring fdatasync and msync calls into the picture, that would otherwise be left entirely out of the test. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
