[sheepdog-users] Fwd: dog vdi check: ovject is incosistent
micha at kovoks.nl
Fri Oct 3 16:21:28 CEST 2014
----- Original Message -----
> From: "Valerio Pachera" <sirio81 at gmail.com>
> To: "Lista sheepdog user" <sheepdog-users at lists.wpkg.org>
> Sent: Friday, October 3, 2014 4:01:20 PM
> Subject: Re: [sheepdog-users] Fwd: dog vdi check: ovject is incosistent
> Hi Micha,
> > decided using the object cache is maybe not the best solution in my
> > situation
> I agree, object cache is not well tested yet.
> Just to understand:
> if you have node A,B,C.
> The guest is running on A.
> Are you killing node A ?
No, i'm killing node C (or B for that matter)
> > but these corrections somehow corrupted the filesystem
> Mmm, that's bad but I didn't experience that without object cache.
> I'm also not using journal.
> Honestly, I don't have clear what's the role of journal option in sheepdog.
> Please, try simply not to use journal and object cache.
As I understand on https://github.com/sheepdog/sheepdog/wiki/Journaling it seems the journal makes it a bit safer to use the '-n' switch on the nodes. And that switch gained quite some performance for me, as did the mount option 'barrier=0'. But because both make the 'write command' -> 'data really on disk' fase a bit more uncertain. I understand that enabling the journal does not really protect you from data loss, but should at least keep your VDI's concurrent in case of a major crash.
Mostly I'm unsure how bad this all is because in my opinion sheepdog should only need to fall back on the journal if the majority of the nodes (in my case 2 out of 3) are crashed, but that is one of my major questions.
So my best option could be to set the -j size=512M,skip option for normal use and maybe only use the available journal in a major failure situation.
More information about the sheepdog-users