* Re: Linux pNFS status meeting 06/03 [not found] ` <20100603172210.GG24994@fieldses.org> @ 2010-06-06 11:11 ` Benny Halevy 2010-06-06 14:34 ` J. Bruce Fields 0 siblings, 1 reply; 2+ messages in thread From: Benny Halevy @ 2010-06-06 11:11 UTC (permalink / raw) To: J. Bruce Fields; +Cc: NFS list On Jun. 03, 2010, 20:22 +0300, "J. Bruce Fields" <bfields@fieldses.org> 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@vger.kernel.org instead. > (To subscribe to linux-nfs@vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TaiAVqoAR/hOA@public.gmane.org) > > NFSv4 mailing list > NFSv4@linux-nfs.org > http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4 ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Linux pNFS status meeting 06/03 2010-06-06 11:11 ` Linux pNFS status meeting 06/03 Benny Halevy @ 2010-06-06 14:34 ` J. Bruce Fields 0 siblings, 0 replies; 2+ messages in thread From: J. Bruce Fields @ 2010-06-06 14:34 UTC (permalink / raw) To: Benny Halevy; +Cc: NFS list On Sun, Jun 06, 2010 at 02:11:21PM +0300, Benny Halevy wrote: > On Jun. 03, 2010, 20:22 +0300, "J. Bruce Fields" <bfields@fieldses.org> 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] Yes. Thanks for the corrections! --b. > > 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@vger.kernel.org instead. > > (To subscribe to linux-nfs@vger.kernel.org: send "subscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TaiAVqoAR/hOA@public.gmane.org) > > > > NFSv4 mailing list > > NFSv4@linux-nfs.org > > http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4 ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-06-06 14:34 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <OFD9CC398A.6555CB30-ON88257736.006D4B55-88257736.006D71E6@us.ibm.com>
[not found] ` <20100603172210.GG24994@fieldses.org>
2010-06-06 11:11 ` Linux pNFS status meeting 06/03 Benny Halevy
2010-06-06 14:34 ` J. Bruce Fields
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.