On 10/11/13, 2:49 AM, Saso Kiselkov wrote: > I've decided to resurrect my original persistent L2ARC webrev from about > a year ago and rework it with additional design advice kindly provided > by Matt Ahrens. Interested folks, please take a preliminary view of this > changeset and let's get the ball rolling on getting this integrated. > > http://cr.illumos.org/~webrev/skiselkov/3525_simplified/ > > This partial rewrite accomplishes several important objectives: > > 1) Makes the design simpler and (I hope) easier to understand. I've cut > it by ~400 lines and it's now following proper naming nomenclature, > plus I got rid of all the encoding/decoding functions. > > 2) More robust. We no longer "taste" the L2ARC device to see if there's > an uberblock there. Instead we store this attribute in the vdev > config (magic numbers are kept as fail safes, of course). > > 3) Faster rebuilds. As before, rebuilds are done in background threads > and in parallel on all available L2ARC devices, so it doesn't block > pool import, but thanks to some restructuring of the way we link the > metadata chain I was able to optimize this phase, so that we saturate > the devices much better (rebuilding ~100GB worth of L2ARC takes ~2 > seconds on my crappy little system). > > Please consider this code alpha for now, as it hasn't seen much exposure > in production yet. I'm currently beating the crap out of it on my backup > machine. Any volunteers willing to help with testing are very much > welcome, especially if you reboot your machine a lot, or have > shared-storage pools capable of simulating ungraceful takeovers. I have > reasonable confidence that it won't trash your data, so worst case is > you'll see a kernel panic (make sure you can capture that if need be). > Please do not deploy into production if you value uptime.
Has anybody had time to look over this webrev yet? I'm getting requests from people to get this upstreamed. Cheers, -- Saso _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
