gvinum + geli + gjournal

[Lev Serebryakov]

Hello, Anthony.
You wrote 23 ноября 2011 г., 7:50:54:

> It seems most admins prefer hardware RAID5, but having a good
> implementation in software for those under tight budgets seems like it
> would be very worthwhile.
  And not so tight budgets, too, as "true" hardware RAID5 cards are
 very expensive, and work rather poor without battery module, which
 adds another ~$300...

>>> 2. Has anyone done any rigorous testing with it?
>>   It depends on your meaning of word ``rigorous'' :)
>>   I'm using it for couple of years, I had several server failures in
>>  this time (panics), Ive chaged two failed drives for same size and
>>  after that migrate to larger HDDs (5x500Gb -> 5x2Tb) non-stop
>>  (almost, growfs need you to unmount FS), and I run some tests in VM
>>  after each change. But there is no formal test-suite (yet, but,
>>  again, see above about lack of "external" interest, which discourage
>>  me).
> Were the panics that you mentioned directly caused by graid5?  If so,
> under what conditions?
   No, it was faulty memory, overheated CPU and other hardware
 problems. My main (and only one physical) server is only cheap
 desktop hardware, nothing fancy like ECC memory or redundant cooling system.

> You might want to base your opinion on the number of downloads the code
> receives rather than responses here.  I, for one, have been using
> FreeBSD since version 1.0, but haven't posted to the mailing lists very
> often at all. ;-)
  :)

> Any other features / bugs I should be aware of?  The data that I'm
  It could be misconfigured: long write queue / long write timeout
 could over-allocate memory. Default settings is very conservative,
 but if you try to tune it for best write performance, you could be
 misleaded by "maxmem" sysctl and belive, that it is hard top border
 for allocated memory. It is, unfortunately, not. I'll change this in
 future, but now you should be conservative in these settings.

> intending to migrate is rather precious.  I cannot afford to lose any of
> it, and will use graid3 if I must.
  I should be sure, that port contains latest version with all latest
 changes, as I've fixed one potential bug (I never encounter it in the
 wild, though), some time ago. I'll check it tonight and notify you.

>>> I have 2 questions regarding graid5:
>>> 1. Why hasn't it made its way to the base FreeBSD distribution yet?
>>> 2. Has anyone done any rigorous testing with it?
>>   BTW, if you could write list of good test-cases which should be in
>> (VM-based) automated test-suite, it will be very helpful.
>>   I could easily miss some corner cases.
>>   But, please, be aware, that this test-suite should be implemented
>> via standard UNIX API plus "disk disconnection," which is possible
>> under VirtualBox 4.x, so tests should be formulated via newfs, file
>> operations, fsck, etc. toolset, not via some internal kernel APIs.

> When time permits, I'll have a look at the code, but it may be a few
> months before I will be able to do so.  I'm rather busy at the moment.

> When you mention "disk disconnection," do you mean *physical*
> disconnection (e.g., before a umount)?
   Yep. To simulate disk failure & disk hot-swap. VirtualBox allows to
 do so (from host OS, of course) and it helps me a lot in graid5
 development.



-- 
// Black Lion AKA Lev Serebryakov <lev at FreeBSD.org>