Re: softdep by default on AMD64
Yeh, cutting edge.. I have system lock/freeze every time with bittorent (aria2 or rtorrent) when net bandwidth 5 mbit/s or more :) This is the point I am getting flak again, please don't pollute the env you're doing it wrong. (ffs+softdep on softraid crypto) Plus a person trying to post to misc@
Re: softdep by default on AMD64
On Thu, Jul 30, 2015 at 2:01 PM, Christian Weisgerber na...@mips.inka.de wrote: On 2015-07-30, Karel Gardas gard...@gmail.com wrote: 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. If you push a beefy machine hard enough (e.g. bulk amd64 package builds), you will suffer occasional softdep crashes. Ack. Net also as the only one from *BSD supports ffs snapshoting, FFS snapshots were added to FreeBSD 15 years ago. Actually it seems they does not support snapshots by default anymore, since they rather support softupdates journaling. Tested on 10.1 and default is what matters here.
Re: softdep by default on AMD64
On Thu, Jul 30, 2015 at 3:36 PM, Karel Gardas gard...@gmail.com wrote: On Thu, Jul 30, 2015 at 2:01 PM, Christian Weisgerber na...@mips.inka.de wrote: On 2015-07-30, Karel Gardas gard...@gmail.com wrote: 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. If you push a beefy machine hard enough (e.g. bulk amd64 package builds), you will suffer occasional softdep crashes. Ack. Net also as the only one from *BSD supports ffs snapshoting, FFS snapshots were added to FreeBSD 15 years ago. Actually it seems they does not support snapshots by default anymore, since they rather support softupdates journaling. Tested on 10.1 and default is what matters here. Assuming by FFS snapshots you mean the snapshots created by mksnap_ffs(8) they are well supported and haven't gone anywhere in FreeBSD 10. Neither are they mutually exclusive with softupdates. Softupdates journaling (SU+J) did have some issues with FFS snapshots but they have been largely resolved now. -Kimmo
Re: softdep by default on AMD64
Karel Gardas wrote: 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. i would suggest interested parties look at wapbl.
Re: softdep by default on AMD64
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-miscm=142170287802566w=2 https://marc.info/?l=openbsd-miscm=142174547612722w=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-miscm=142250784228719w=2 https://marc.info/?l=openbsd-miscm=142294185000751w=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?
Re: softdep by default on AMD64
On Thu, Jul 30, 2015 at 11:30:36AM +0200, Karel Gardas wrote: Spent already some time in netbsd/bitrig wapbl code to see what's relevant for Open and how to structure it to small sensible patches to push for review. This will take some energy and time indeed, the problem is that anytime the word bitrig comes to Open mailing list, it's either ignored or start kind of non-engineering discussion. So it's indeed a beg to get an answer to question: is anytime spent in netbsd/bitrig wapbl/snapshoting code to review, understand, analyse, prepare for review to Open wasted or not? If, even socially, it's wasted, then indeed, it's more productive and beneficial to project to spent it on different things... If you were serious about approaching a project like this, you would determine the answers to the above questions yourself. Requirement analysis is part of the project. As for social concerns, you don't have to worry about any of that. Just make sure the technical work you produce is sound and any 3rd party code you use make use of as part of your work is suitably licensed. I hope your next mail comes in a few weeks and has a small and correct vfs/softdep bug fix attached to it. That would indicate progress. But if you just keep asking about what to do, then your time (and the time anyone else is spending on this discussion) will probably be wasted. Before expecting help and direction you'll have to demonstrate a fair amount of self-reliance to avoid the impression that you'll drain the resources of anyone willing to help you.
Re: softdep by default on AMD64
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! Your mail sounds like a beg. Perhaps I am being too sensitive. Any coding direction that has people working on it, will eventually have some effect. But it requires code study, not running wc. You don't grow good vegetables in your own garden by testing the plumpness of a tomato at Safeway. I could run wc until the cows go home, and not find or fix a single vfs layer bug. I am not trying to be crass -- I am being entirely honest about how software improves. It improves because someome tries. Period. Bugs rarely fix themselves when there is little actual attention / effort. You do not seem to be approaching the code in any way at all; wc annotation comes off like mailing list stroking. Perhaps you don't have capabilities in this area, honestly, I don't have vfs layer patience this year either, but at least I don't try to fake it... A vector without force behind it is not a useful vector.
Re: softdep by default on AMD64
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-miscm=142170287802566w=2 https://marc.info/?l=openbsd-miscm=142174547612722w=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-miscm=142250784228719w=2 https://marc.info/?l=openbsd-miscm=142294185000751w=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?
Re: softdep by default on AMD64
On Tue, Jul 28, 2015 at 06:19:11AM -0700, Chris Cappuccio wrote: ?? ?? [art.is...@yandex.ru] wrote: On Fri, Jul 24, 2015 at 07:56:07AM +0100, Nicholas Marriott wrote: generally reliable HAHAHAHAHA Why irony? It's more or less true for ALL modern computing system. Think of it as a selling point. OpenBSD ffs softdep: On the cutting edge of reliability! Yeh, cutting edge.. I have system lock/freeze every time with bittorent (aria2 or rtorrent) when net bandwidth 5 mbit/s or more :) (ffs+softdep on softraid crypto)
Re: softdep by default on AMD64
Артур Истомин wrote: Yeh, cutting edge.. I have system lock/freeze every time with bittorent (aria2 or rtorrent) when net bandwidth 5 mbit/s or more :) (ffs+softdep on softraid crypto) I've been getting I/O errors and other strange problems with softraid crypto, both with and without softdep. I was planning on investigating a little more tonight, actually. What kind of drive is yours on? Do you drop to ddb on reboot/shutdown?
Re: softdep by default on AMD64
Артур Истомин wrote: On Tue, Jul 28, 2015 at 06:19:11AM -0700, Chris Cappuccio wrote: ?? ?? [art.is...@yandex.ru] wrote: On Fri, Jul 24, 2015 at 07:56:07AM +0100, Nicholas Marriott wrote: generally reliable HAHAHAHAHA Why irony? It's more or less true for ALL modern computing system. Think of it as a selling point. OpenBSD ffs softdep: On the cutting edge of reliability! Yeh, cutting edge.. I have system lock/freeze every time with bittorent (aria2 or rtorrent) when net bandwidth 5 mbit/s or more :) (ffs+softdep on softraid crypto) 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-miscm=142170287802566w=2 https://marc.info/?l=openbsd-miscm=142174547612722w=2 So a tempered warning would probably be best.
Re: softdep by default on AMD64
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-miscm=142170287802566w=2 https://marc.info/?l=openbsd-miscm=142174547612722w=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-miscm=142250784228719w=2 https://marc.info/?l=openbsd-miscm=142294185000751w=2
Re: softdep by default on AMD64
Ffs + softdep + soft raid crypto: Sounds like you have a case of Bill Murray http://m.youtube.com/watch?v=bOtMizMQ6oM On 29 Jul 2015 18:33, Michael McConville mmcco...@sccs.swarthmore.edu wrote: Артур Истомин wrote: Yeh, cutting edge.. I have system lock/freeze every time with bittorent (aria2 or rtorrent) when net bandwidth 5 mbit/s or more :) (ffs+softdep on softraid crypto) I've been getting I/O errors and other strange problems with softraid crypto, both with and without softdep. I was planning on investigating a little more tonight, actually. What kind of drive is yours on? Do you drop to ddb on reboot/shutdown?
Re: softdep by default on AMD64
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-miscm=142170287802566w=2 https://marc.info/?l=openbsd-miscm=142174547612722w=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.
Re: softdep by default on AMD64
?? ?? [art.is...@yandex.ru] wrote: On Fri, Jul 24, 2015 at 07:56:07AM +0100, Nicholas Marriott wrote: generally reliable HAHAHAHAHA Why irony? It's more or less true for ALL modern computing system. Think of it as a selling point. OpenBSD ffs softdep: On the cutting edge of reliability!
Re: softdep by default on AMD64
generally reliable HAHAHAHAHA On Thu, Jul 23, 2015 at 09:31:59PM -0400, Michael McConville wrote: On Thu, Jul 23, 2015 at 06:49:55PM -0600, Theo de Raadt wrote: There was a great discussion about softdep recently: https://marc.info/?t=14216401691r=1w=2 It needs extra memory, so the FAQ warns against its use on really old architectures. tedu@ described the two main deterrents: https://marc.info/?l=openbsd-miscm=142294185000751w=2 Might it be worth making default for AMD64? The performance gain is big in many cases. There is no way this diff is going in. When softdep is 100% reliable, then we can talk. Enabling it prematurely is ridiculous. Considering the defects are clearly described as lockups, disk space corruption -- with such a suggestion I must ask --who's side are you on?? The first issue that Ted mentions is just characteristic of soft updates, right? He discusses it more here: https://marc.info/?l=openbsd-miscm=142250784228719w=2 The second one sounds specific to implementation bugs. I didn't know how well those had been combed out. Here's another diff. Someone who knows more than I do about soft updates can probably word it better. Index: faq/faq14.html === RCS file: /cvs/www/faq/faq14.html,v retrieving revision 1.253 diff -u -p -r1.253 faq14.html --- faq/faq14.html2 Jul 2015 05:49:04 - 1.253 +++ faq/faq14.html24 Jul 2015 01:25:03 - @@ -913,6 +913,12 @@ with soft updates. /pre/blockquote p +While soft updates are widely used and generally reliable, they can worsen the +impact of I/O errors. Also, if many small files are quickly modified on a slow +disk, the fileystem may struggle to cope with the accumulating deferred +updates. + +p Note to sparc users: Do not enable soft updates on sun4 or sun4c machines. These architectures support only a very limited amount of kernel memory and cannot use this feature. However, sun4m machines are Index: faq/obsd-faq.txt === RCS file: /cvs/www/faq/obsd-faq.txt,v retrieving revision 1.39 diff -u -p -r1.39 obsd-faq.txt --- faq/obsd-faq.txt 5 Jun 2015 12:04:13 - 1.39 +++ faq/obsd-faq.txt 24 Jul 2015 01:25:04 - @@ -11531,6 +11531,11 @@ that has one partition sd0a that we wish /dev/sd0a / ffs rw,softdep 1 1 +While soft updates are widely used and generally reliable, they can worsen the +impact of I/O errors. Also, if many small files are quickly modified on a slow +disk, the fileystem may struggle to cope with the accumulating deferred +updates. + Note to sparc users: Do not enable soft updates on sun4 or sun4c machines. These architectures support only a very limited amount of kernel memory and cannot use this feature. However, sun4m machines are fine.
Re: softdep by default on AMD64
On 2015/07/23 18:49, Theo de Raadt wrote: There is no way this diff is going in. When softdep is 100% reliable, then we can talk. Even if 100% reliable, by design it tends to cause problems on smaller filesystems as space is not reclaimed for removed files until after some delay.
Re: softdep by default on AMD64
On Fri, Jul 24, 2015 at 07:56:07AM +0100, Nicholas Marriott wrote: generally reliable HAHAHAHAHA Why irony? It's more or less true for ALL modern computing system.
Re: softdep by default on AMD64
Michael McConville wrote: There was a great discussion about softdep recently: https://marc.info/?t=14216401691r=1w=2 It needs extra memory, so the FAQ warns against its use on really old architectures. tedu@ described the two main deterrents: https://marc.info/?l=openbsd-miscm=142294185000751w=2 Might it be worth making default for AMD64? The performance gain is big in many cases. I'm not sure the tradeoff is such that we can safely switch to softdep by default. Sure, you probably want it, but it remains the case that softdep users report more panics than those who don't use it. Our cost/benefit analysis is skewed towards minimzing risk. Rightly so, imo, even in the case that most users will choose differently. Index: editor.c === RCS file: /cvs/src/sbin/disklabel/editor.c,v retrieving revision 1.295 diff -u -p -r1.295 editor.c --- editor.c 8 May 2015 12:15:50 - 1.295 +++ editor.c 24 Jul 2015 00:16:08 - @@ -51,6 +51,12 @@ #define NUMBOOT 0 #endif +#if defined(__amd64__) +#define MNT_OPTS rw,softdep Rationale aside, this would never fly. We try to keep the tree as free of arch dependent ifdef as much as possible, doubly so in userland. Definitely the wrong place to be making this change (for future reference, in case you have any other changes for amd64 :)). For that matter, it's also undesirable to have platforms deviate from the default. In some cases, that's unavoidable, but exceptions should be exceptional.
Re: softdep by default on AMD64
There is no way this diff is going in.
When softdep is 100% reliable, then we can talk.
Enabling it prematurely is ridiculous. Considering the defects
are clearly described as lockups, disk space corruption -- with
such a suggestion I must ask --who's side are you on??
There was a great discussion about softdep recently:
https://marc.info/?t=14216401691r=1w=2
It needs extra memory, so the FAQ warns against its use on really old
architectures.
tedu@ described the two main deterrents:
https://marc.info/?l=openbsd-miscm=142294185000751w=2
Might it be worth making default for AMD64? The performance gain is big
in many cases.
Index: editor.c
===
RCS file: /cvs/src/sbin/disklabel/editor.c,v
retrieving revision 1.295
diff -u -p -r1.295 editor.c
--- editor.c 8 May 2015 12:15:50 - 1.295
+++ editor.c 24 Jul 2015 00:16:08 -
@@ -51,6 +51,12 @@
#define NUMBOOT 0
#endif
+#if defined(__amd64__)
+#define MNT_OPTS rw,softdep
+#else
+#define MNT_OPTS rw
+#endif
+
/* structure to describe a portion of a disk */
struct diskchunk {
u_int64_t start;
@@ -1892,9 +1898,10 @@ mpsave(struct disklabel *lp)
if (fstype == FS_SWAP) {
fprintf(fp, %s%c none swap sw\n, bdev, 'a'+j);
} else if (mi[i].mountpoint) {
- fprintf(fp, %s%c %s %s rw 1 %d\n, bdev,
+ fprintf(fp, %s%c %s %s %s 1 %d\n, bdev,
'a' + j, mi[i].mountpoint,
- fstypesnames[fstype], j == 0 ? 1 : 2);
+ fstypesnames[fstype], MNT_OPTS,
+ j == 0 ? 1 : 2);
}
}
fclose(fp);
x1
Re: softdep by default on AMD64
On Thu, Jul 23, 2015 at 06:49:55PM -0600, Theo de Raadt wrote: There was a great discussion about softdep recently: https://marc.info/?t=14216401691r=1w=2 It needs extra memory, so the FAQ warns against its use on really old architectures. tedu@ described the two main deterrents: https://marc.info/?l=openbsd-miscm=142294185000751w=2 Might it be worth making default for AMD64? The performance gain is big in many cases. There is no way this diff is going in. When softdep is 100% reliable, then we can talk. Enabling it prematurely is ridiculous. Considering the defects are clearly described as lockups, disk space corruption -- with such a suggestion I must ask --who's side are you on?? The first issue that Ted mentions is just characteristic of soft updates, right? He discusses it more here: https://marc.info/?l=openbsd-miscm=142250784228719w=2 The second one sounds specific to implementation bugs. I didn't know how well those had been combed out. Here's another diff. Someone who knows more than I do about soft updates can probably word it better. Index: faq/faq14.html === RCS file: /cvs/www/faq/faq14.html,v retrieving revision 1.253 diff -u -p -r1.253 faq14.html --- faq/faq14.html 2 Jul 2015 05:49:04 - 1.253 +++ faq/faq14.html 24 Jul 2015 01:25:03 - @@ -913,6 +913,12 @@ with soft updates. /pre/blockquote p +While soft updates are widely used and generally reliable, they can worsen the +impact of I/O errors. Also, if many small files are quickly modified on a slow +disk, the fileystem may struggle to cope with the accumulating deferred +updates. + +p Note to sparc users: Do not enable soft updates on sun4 or sun4c machines. These architectures support only a very limited amount of kernel memory and cannot use this feature. However, sun4m machines are Index: faq/obsd-faq.txt === RCS file: /cvs/www/faq/obsd-faq.txt,v retrieving revision 1.39 diff -u -p -r1.39 obsd-faq.txt --- faq/obsd-faq.txt5 Jun 2015 12:04:13 - 1.39 +++ faq/obsd-faq.txt24 Jul 2015 01:25:04 - @@ -11531,6 +11531,11 @@ that has one partition sd0a that we wish /dev/sd0a / ffs rw,softdep 1 1 +While soft updates are widely used and generally reliable, they can worsen the +impact of I/O errors. Also, if many small files are quickly modified on a slow +disk, the fileystem may struggle to cope with the accumulating deferred +updates. + Note to sparc users: Do not enable soft updates on sun4 or sun4c machines. These architectures support only a very limited amount of kernel memory and cannot use this feature. However, sun4m machines are fine.
