geom_raid5 inclusion in HEAD?

Arne Wörner arne_woerner at
Wed Nov 7 10:57:33 PST 2007

--- Ulf Lilleengen <lulf at> wrote:
> - Many style(9) issues.
Hmm... Would "cb" help? R some function too long? I tried to comply to Pawel's
style, but obviously I deviated from it after some weeks... :)
Could give me an example of the worst issue?

> - Lack of documentation. There are many small comments, but there is little
>   description on top of functions describing their purpose and what they do.
>   This makes it hard to get into it for reviewers and other developers.
Hmm... Yup...

There r interface functions to the GEOM system: ..._start(), ..._done(),
..._create(), and so on...
Then there r 2 worker threads (one for the graid5 start queue (...worker()) and
one for the graid5 done queue (...workerD()).
The other functions r helper functions...
I could add the function-purpose-comment in PP and then try to merge it to TNG
and TOS...

> - As to the code logic itself I was a bit sceptic about having the malloc
> saving   
>   queue. Does it really improve performance that much? It's just the sort of 
>   thing that could easily lead to bugs.
Hmm... if I understood correctly, FreeBSD's kernel memory suffers under
fragmentation, if many big mem areas r needed... There might be even a dead
lock, if UFS uses 64kb block size... So I thought it would be a good idea to
avoid those sleeps but "hamster-ing" the big chunks... :) But I am not sure
anymore, that it improved performance (but performance was the reason for

> - I also wonder a bit why you use two worker threads, as this also increases
>   complexity (but again, does it improve performance to the point that it's
>   worth it?).
Hmm... I think so... At least on MP boxes, since both threads do some XOR-ing
(worker() uses XOR for writing "full-stripes" (where no read is necessary) and
bcopy; and workerD() uses XOR after the old data/parity has been read)...

> And last but not least: All of this have to be reviewed before going into the
> tree, and there are not many people who can do that right now. However, I
> really like your work and would gladly help improving it.
OK... review sounds good... maybe we should concentrate on PP then (it is quite
space (in comparison to TNG but not TOS)+time (in comparison to TOS; maybe in
comparison to TNG, too?) efficient and has a read cache)? Although fluffles
favors TNG, although it is quite nasty (a write request of size 4KB costs 3
full stripes ((<number of disks>-1)*<stripe size>) plus 2*128KB... *giggle*)...


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the freebsd-current mailing list