On Jun. 03, 2010, 20:22 +0300, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Wed, Jun 02, 2010 at 12:55:33PM -0700, Marc Eshel wrote: >> Meeting on Thursday 06/03/10 at 9:30 AM pacific time (12:30 PM UMICH time) > > Rough notes (more distracted than usual, apologies): > > > Rough agenda. Note Benny and Boaz will miss this one: Actually, not this one (prob. cut'n'pase typo?) [And correcting mailing list on the Cc] Benny > > 1. upstream status/merge plans (trond, bfields) > - 2.6.34 released, 2.6.35 merge window come and gone, > - That means 2.6.35 is now for (certain) bug fixes only, new > development will be queued for 2.6.36. > - I've started a for-2.6.36 branch for the server, just small > bugfixes so far. > - (Trond absent). > > 2. State of pNFS tree (bhalevy) > - new 2.6.34 and 2.6.33 versions released. Hoping to leave > 2.6.33 only now. > > 3. Client > 3.1. Client pNFS status > - (missed some.) > - Andy working on reboot recovery? > - Boaz: what testing at bthon? > - Andy: forgetful model > - Boaz: Note that would require changes to object > (and block?) server implementations. (Changes to > generic server may be required, e.g. to handle > DELAY on layout recall callback?) > 3.2. Client state management design documentation (trond) > - (Trond absent) > 4. Server > 4.1. Todo's for minimal 4.1 server (bfields) > - have 4.1 pynfs running against linux server, ironing > out some problems; our local pynfs changes here: > git://linux-nfs.org/~bfields/pynfs41.git > (Main problem now is a SERVERFAULT error that prevents > running all tests at once. Another resource > accounting bug, maybe?) > - contemplating porting pynfs server reboot recovery > tests from 4.0 pynfs to 4.1 pynfs. > - hoping to start writing new server 4.1 tests over > the next couple weeks. > 4.2. pnfs > pnfs/gfs2: > - running basic pnfs/gfs2 performance tests. Results > don't show expected scaling. Backend appears OK > (tested by reading 3 different files from each of 3 > different gfs2 nodes). Perhaps gfs2 isn't scaling > reads to shared files as expected; test that > hypothesis by > a) simultaneous reads from shared files over > gfs2 (without pnfs in the way) > b) modifying pnfs/gfs2 to work around the > problem by handing out single-DS layouts > (instead of striping). > - sent in a couple gfs2 patches. Note one was an > "obvious" fix, but may have broken stuff (e.g. > getdeviceinfo) that depended on previous buggy > behavior? Will test. > exofs: > - Boaz working on results; plans to report in next week > or so. > > 5. redhat status (steved) > - continuing to backport client and server code > - should have result at bakeathon. > 6. bakeathon plans > - ann arbor: Heard from everyone I expect but EMC. I'll try to get > out some logistical information next week. > - boston (Sorin working on hotel information?) > - (Sorin absent?) > 7. new business > 8. next meeting > - next thursday as usual. (Probably skip thursday after next.) > > --b. > _______________________________________________ > NOTE: THIS LIST IS DEPRECATED. Please use linux-nfs@xxxxxxxxxxxxxxx instead. > (To subscribe to linux-nfs@xxxxxxxxxxxxxxx: send "subscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxxx) > > NFSv4 mailing list > NFSv4@xxxxxxxxxxxxx > http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
