Google Summer of Code 2007

On this page I will keep everyone updated on what I'll be doing, why I'm doing it, and when I'm doing it.

I've created a branch structure something like: //depot/projects/soc2007/lulf/<gvinumbranch>

This way i have a gvinum_main branch where everything will be imported, and a lot of other small branches where I will work on specific issues. Then I will later integrate them into the gvinum_main branch.

2007-05-09

Here's a summary of what I've done so far, and might do soon.

I've committed some work on the setstate functionality making it possible to be used again. Setstate now works on subdisks, plexes, volumes and drives. I have also been thinking of and made error codes to be used internally in gvinum to sort of help me see what happens when debugging etc.

Other than that, I've rewritten the resetconfig a bit to prevent (what i think is) a race condition that was introduced with the new event system. (Testing in progress right now, so I'll commit it as soon as my test-build-tree is up-to-date.)

What I is thinking to do next is to begin fix the remaining issues with the new event system.

Also, these are my initial plans to complete in the near future:

Integrate attach/detach routines
Integrate concat/stripe/mirror routines

2007-05-26

More information. It feels a bit duplicate work, but this is perhaps a place to explain more in detail of my work.

Sort of a summary of what I've done this week, and a bit on my work-in-progress.

Parity rebuild initiated by user should work now. I've created two methods for
- this purpose. One to send a new parity check/rebuild bio at a given offset, and one to handle the completed request (which includes calling the sender again if the rebuild/check is not finished).
Rebuilding a degraded plex. I did a little abstraction on the send function
- that is used by parity rebuild/check to use it for this purpose as well. I did make a different complete-function because it was different in several ways.
Created events for these routines, as well as modifying userland gvinum to
- send the correct requests.

Now, I was going to test this rebuild of degraded plexes a bit, but I'd like to have the attach/detach routines to do this instead of zeroing parts of the drive to see if it behaves correctly (avoiding erasing gvinum magic etc. But I'll probably try that first). I have the code for this from old gvinum, so I'm currently on my way to implement it for the new gvinum as well.

So, off to more coding

2007-06-14

So, finally the exams are over, and I've been able to work sort of full-time on my project the last days. What I've done is:

Implemented attach/detach routines. This makes it possible to attach a subdisk/plex to a plex/volume, or detach a plex/subdisk from a volume/plex. The detach routine makes sure all connections between the objects are broken correctly, and only if it's possible (unless forced ofcourse). The attach routine makes sure the objects are correctly connected together again, and that a plex that misses subdisks includes them in the previous size when calculating the new size (so we don't get wrong sizes on the plexes).
Tested rebuild of degraded plexes. The detach/attach routines enabled me to check if the rebuild of a degraded raid5 plex could work. And it did! This means (and this is something that I really missed in old gvinum), that when a drive fails, you can detach the failed subdisk, create a new subdisk on the plex (and it will check if the plex "misses" a subdisk), and then use 'start <plexname>' to rebuild the plex (The state of the plex must be degraded and the subdisk you wish to rebuild must be stale) and you're good to go!
Fix some small bugs.
Implement syncing of plexes. This is done by having a read BIO being sent down to the healthy plex, and when it is finished, it issues a write BIO of that data to the destination plex (which is stored in BIOs private fields). This means one can now add a mirror to a volume, and have the new plex to be synced from the original. However, I also discovered some bugs regarding mirrored plexes that I will address in the near future.

Next on my schedule is to hunt some weird state bugs where the state is not correctly set, as well as the mirrored plex problems I've seen. Also, I need to guarantee that a plex sync is up-to-date (that no data is written to the synced plex in the meantime).

2007-06-28

Finally, an update on what I've been doing since the last time. This time I have a lot of small changes that have been done:

Implement initialization of RAID5-Arrays. This basically writes zeros over everything and makes sure parity is correct.
Fix a bug with mirror code. The BIO that was sent to the volume duplicated the bio_completed field so that it was a multiple of bio_length.
When a mirrored plexes are syncing, all requests after and including the first _write-request_ are delayed until syncing is finished.
Allow rebuilding a RAID-5 array while it is in use (e.g. mounted). Delay requests that are in conflict with the rebuild, but allow requests on the already rebuilt part to be run.
Allow subdisks to come up automagically after rebuild.
Allow stripesizes not divideable by the subdisk size. A regression in the new gvinum code prevented this.
Modify the event system to contain two intmax_t fields, so we won't have to allocate/deallocate pointers all the time when passing args to gv_post_event.
Add support for the rename and move commands to new gvinum. The code has been rewritten for the new gvinum.
Fix a bug in the code for degraded writes to a RAID5-array, where only zeros were written.
Other minor bug/style fixes.

Next, I'm going to implement concat/stripe/mirror functionality. I already have some code from previous work I did, so I just need to adapt it to new gvinum, as well as change some ugly parts. There are some small facade-changes left, but I will do this after the last of the original vinum features is completed. Also, I will try write a nice status report, and get a testable patch out by the time the report is finished.

2007-07-04

Since last post, there has been many small bugfixes to gvinum. After some debating with myself on how I should implement concat/stripe/mirror, I think I got it pretty much right. The event system changed gvinum a lot, so I had to rewrite most of the code I already had on this.

I have done a lot of testing this week, and I made a test plan that I’m going to follow. Hopefully, I’ll also be able to create som automatic tests for this.

I’ve even been a good boy and updated the gvinum manpage! I added some examples to the manpage as well, so that it’s easier to get into gvinum for inexperienced users (not sure if we want gvinum to live even longer, but ).

Since last post I haven’t really done that much do gvinum, but a few things.

I added a few automated test-scripts to check if a volume behaves properly
Go through test-plan and make sure that gvinum passes the tests.
I’ve been thinking a lot on how to best implement growing RAID-5 plexes.
I’ve implemented growing of RAID-5 plexes.

Now, the first and second points are quite boring to do, but I had to do it. Now the last points were trickier, since I didn’t really know where I should start. Finally I decided the best way was to let the plex overwrite itself! A more detalied explanation can be found in the TODO of my perforce branch. I need to test the implementation a bit now. Other than that, I’ve been a bit lazy on my own work this week, and tried to help other students with reviews etc.

A lot of small problems with weird states being set was also fixed, since this can be very confusing if you havent used gvinum much.

What I’d like to do next, is create a set of testscripts that I can use to test quickly and easily with. I also noticed that it would be nice to have a similar command like ‘mirror’ for RAID-5 volumes. This could be used like this: ‘gvinum raid5 ‘. Other than that, I’ve started to think on how I’m going to implement raid-5 resizing and other goals in my proposal

2007-07-17

Since last post I haven’t really done that much do gvinum, but a few things.

I added a few automated test-scripts to check if a volume behaves properly
Go through test-plan and make sure that gvinum passes the tests.
I’ve been thinking a lot on how to best implement growing RAID-5 plexes.
I’ve implemented growing of RAID-5 plexes.

2007-08-06

The last couple of weeks I’ve tested and done bugfixing and cleanup of gvinum code. I refactored some parts to make the code belong where it seems logical. I modified some of the plex-code to make it look more like the way RAID-5 offset-calculation and request-handling is done.

I also implemented growing for striped plexes, but that was quite easy since I could reuse most of the code for growing RAID-5 plexes. Unfortunately I was sick for a week and unable to work.

What remains now is to do more testing (can’t get enough), and write and update documenatation on gvinum. I have updated patches for gvinum for both RELENG_6 and CURRENT.

Also, I created a new perforce-branch called gvinum_cache. I’ve currently implemented a read/write-cache to check if this would give much speed-up for gvinum. It’s not very nice for reliability, but could be an option for those who want better performance.

2007-08-17

More status updates... I've been fixing many small gvinum bugs the last couple of weeks:

The state of gvinum objects were changed after reloading module. This meant that objects got the wrong state when gvinum was brought up.
Made gvinum always use the most recent configuration it finds when setting object states.
Make sure the newest drive is always the newest, and not the first in the drivelist, as was previously assumed.
Add "growable"-state to be used when a plex is ready to be grown.
Allow a plex to be rebuilt even though it's also growable.
Do not change the size of the volume until the plex is completely grown.
Add status of growing and rebuild of a plex in the list output.
Prevent rebuild to take over the I/O system increasing access-count at the start and end of the rebuild.

Probably a couple of other fixes as well. Also, I've updated the vinum-examples page in the handbook to reflect new features and more practical examples. I've posted a "call for testers" on current@, arch@ and geom@, and have received some response from people who are willing to help me test. Thanks to them.

2009-03-28

The gvinum SoC project was committed today.