W.r.t. code or fixes, I'm afraid this is not only about developer work but probably also about simple work analysis and kind of direction discussion. So far what I've read is that softdep does have some unreliability issues on somehow limited platforms: either small kernel memory or slow disk drive or even buggy disk drive. So in ideal world this code may run reliable, the problem is that make it reliable also in limited world may be a huge amount of work. I've not tried to compare softdep in Open and Free, but the difference in just code size is quite huge: Free: sys/ufs/ffs/*softdep* : 10k lines Open: sys/ufs/ffs/*softdep* : 4k lines
Yes, Free also adds softdep journaling. on the other hand Net completely abandoned softdep in favour of wapbl, this thing is interesting since it's about ~1k lines. Net also as the only one from *BSD supports ffs snapshoting, this is about another ~2k lines of code. Surely I count with ideal world situation and that related functionality is in related files, still some code spreads into another files, but I still hope this kind of shows some rough picture here. The question is what's better direction for OpenBSD, either if to spend time on softdep which will probably also involve looking into Free code for possible fixes or to go more Net route and bring wapbl to the table. Any word on that would be appreciated. Thanks! On Thu, Jul 30, 2015 at 8:21 AM, Theo de Raadt <dera...@cvs.openbsd.org> wrote: >> Theo de Raadt wrote: >> > > I understand that you guys are having fun with this. If you think this >> > > is actually an issue, though, it's probably a good idea to suggest an >> > > FAQ change. "Generally reliable" is a pretty lukewarm review compared to >> > > the current FAQ, which doesn't mention any downsides: >> > > >> > > http://www.openbsd.org/faq/faq14.html >> > > >> > > However, some long-time project members find soft updates trustworthy: >> > > >> > > https://marc.info/?l=openbsd-misc&m=142170287802566&w=2 >> > > >> > > https://marc.info/?l=openbsd-misc&m=142174547612722&w=2 >> > > >> > > So a tempered warning would probably be best. >> > >> > Whoa there. >> > >> > We do not get bug reports of enough quality to determine what >> > the people running into these problems are doing. >> > >> > Maybe they are just shooting themselves in the foot? >> > >> > Maybe people are using pf or ssh incorrectly and shooting themselves >> > in the foot? Should we change documentation to clarify >> > >> > * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES >> > * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF >> > * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR >> > * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES >> > * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN >> > * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF >> > * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. >> > >> > Come on Micheal. You could focus developer attention on improving >> > software (which requires "power users" to file better bug reports). >> > >> > Instead, your comments here suggest developers change web pages. >> > From my perspective, what I see is very frustrating. >> >> The additional problems that come with I/O errors are inherent to soft >> updates rather than bugs in their implementation, no? >> >> https://marc.info/?l=openbsd-misc&m=142250784228719&w=2 >> >> https://marc.info/?l=openbsd-misc&m=142294185000751&w=2 > > Michael, unless the code gets fixed -- what is the difference? > > Who do you hold responsible? The FAQ or the code? If you hold the > code responsible, what part will you play? >
