Incomplete writes for leveldb should just result in lost updates, not corruption. Also, we do stop writes before the snapshot is initiated so there should be no in-progress writes to leveldb other than leveldb compaction (though that might be something to investigate). -Sam On Fri, Mar 22, 2013 at 7:26 AM, Chris Mason <clmason@xxxxxxxxxxxx> wrote: > Quoting Alexandre Oliva (2013-03-22 10:17:30) >> On Mar 22, 2013, Chris Mason <clmason@xxxxxxxxxxxx> wrote: >> >> > Are you using compression in btrfs or just in leveldb? >> >> btrfs lzo compression. > > Perfect, I'll focus on that part of things. > >> >> > I'd like to take snapshots out of the picture for a minute. >> >> That's understandable, I guess, but I don't know that anyone has ever >> got the problem without snapshots. I mean, even when the master copy of >> the database got corrupted, snapshots of the subvol containing it were >> being taken every now and again, because that's the way ceph works. > > Hopefully Sage can comment, but the basic idea is that if you snapshot a > database file the db must participate. If it doesn't, it really is the > same effect as crashing the box. > > Something is definitely broken if we're corrupting the source files > (either with or without snapshots), but avoiding incomplete writes in > the snapshot files requires synchronization with the db. > > -chris > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
