<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 16, 2016 at 10:50 PM, AP <span dir="ltr"><<a href="mailto:sheepdog@inml.weebeastie.net" target="_blank">sheepdog@inml.weebeastie.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, May 02, 2016 at 06:04:53PM +0900, Hitoshi Mitake wrote:<br>
> On Sun, May 1, 2016 at 12:14 PM, AP <<a href="mailto:sheepdog@inml.weebeastie.net">sheepdog@inml.weebeastie.net</a>> wrote:<br>
><br>
> > On Tue, Apr 26, 2016 at 07:20:15PM -0700, Hitoshi Mitake wrote:<br>
> > > sheep can corrupt its cluster by diskfull with recovery process. For<br>
> > > avoiding this problem, this patch adds a new option -F to dog cluster<br>
> > > format. If this command is passed during cluster formatting, every<br>
> > > sheep process of the cluster skips recovery if there is a possibility<br>
> > > of diskfull during recovery.<br>
> ><br>
> > I'm a little confused and am wondering if I am reading this incoorectly.<br>
> ><br>
> > This sounds like the default is to set up the cluster in such a way that<br>
> > it'll corrupt itself.<br>
> ><br>
> > Shouldn't it be the other way around? That the default should leave you<br>
> > safe and you have the option of running naked through the poison ivy<br>
> > if that's your idea of fun.<br>
> ><br>
> > Or did I miss something?<br>
><br>
> The default setup will corrupt the cluster if there is no enough space for<br>
> recovery as you say. However, the new option can result a situation that<br>
> some objects lack its enough replicas. Maybe adding a new option for<br>
> killing the cluster itself when there's no enough space would be good.<br>
<br>
</span>Sorry for not replying earlier. Life is a mix of sleep, work and sleep,<br>
atm. :/<br>
<br>
Unfortunately I don't understand the above. Specifically "can result<br>
a situation that some objects lack its enough replicas". Lack what<br>
exactly? :)<br>
<br>
It sounds like the default is to permit overcommit which can result in<br>
corruption when the space is not there at a critical time. If this is<br>
the case then this should be a conscious decision made by the admin and<br>
the default is to go "Your data is precious - have enough space for what<br>
you want." It'd be the option of least surprise.<br>
<br>
If I'm barking up the wrong tree (possible - I'm not sure what you<br>
meant in your reply) then my apologies. Would love a clarificaiton,<br>
time permitting.<br>
<br>
Hopefully I'm not too late in replying.<br></blockquote><div><br></div><div>Sorry for my late reply. As you point, the default can result corrupted state if there is no space. Turning on the new feature by default would be reasonable. How do you think?</div><div><br></div><div>Anyway, careful capacity planning is required for scalable distributed storage...</div><div><br></div><div>Thanks,</div><div>Hitoshi</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
AP<br>
</font></span></blockquote></div><br></div></div>