On Fri, Jul 10, 2015 at 9:34 PM, Chris Cappuccio wrote:
> My first impression, offlining the drive after a single chunk failure
> may be too aggressive as some errors are a result of issues other than
> drive failures.
Indeed, it may look as too aggressive, but is my analysis written in
comment c
Karel Gardas [gard...@gmail.com] wrote:
> Hello,
>
> I think I've found a bug on software RAID1 implementation of handling
> write errors. IMHO code should check if every write to every chunk
> succeed. If not, then there is an error which it needs to handle.
> Proposed patch handles such error by
On octeon, the single-processor kernel does not work quite right when
booted with multiple cores. Each core begins to boot the system
independently, as if there were no other CPUs, leading to a totally
mixed-up state. The following patch alters the MP init core selection
logic a little and enables
Hello,
I think I've found a bug on software RAID1 implementation of handling
write errors. IMHO code should check if every write to every chunk
succeed. If not, then there is an error which it needs to handle.
Proposed patch handles such error by off-lining the problematic drive.
The patch compile
On Fri, Jul 10, 2015 at 07:10:00AM -0500, Vladimir Támara Patiño wrote:
>
> Looks good to me.
>
> I though it was necessary to include __mb_cur_max in _locale_t (as FreeBSD
> and DragonFly do in their xlocale_ctype in mblocal.h) but just now I noticed
> that it is already included in lc_ctype->rl
This fixes a typo in the imsg example.
Index: lib/libutil/imsg_init.3
===
RCS file: /repo/OpenBSD/src/lib/libutil/imsg_init.3,v
retrieving revision 1.12
diff -u -p -u -r1.12 imsg_init.3
--- lib/libutil/imsg_init.3 11 Jun 2015 19
Looks good to me.
I though it was necessary to include __mb_cur_max in _locale_t (as FreeBSD
and DragonFly do in their xlocale_ctype in mblocal.h) but just now I noticed
that it is already included in lc_ctype->rl_citrus_ctype
Thanks for your work.
--
Dios, gracias por tu amor infinito.
--
