In this case, I think Alexandre is scanning for zeros in the file. The incomplete writes will definitely show that. -chris Quoting Samuel Just (2013-03-22 13:06:41) > 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
