Hide Forgot
Lets track the progress here. ------------------ From: Shehjar Tikoo <shehjart> Date: Wed, Jul 15, 2009 at 6:07 AM To: dl-hacking <dl-hacking> Hi Folks Here is the summary of the points discussed in the meeting a few mins back. The meeting dealt with the items to be added to the personal tasks list of developers for the NFSv3 xlator effort. Translator Responsibilities =========================== AFR - Vikas DHT - Avati Posix - Shehjar RA,WB - Raghavendra Unify,io-cache - Gowda Steps towards NFSv3 support =========================== 1. Create new branch. 2. Change fop prototypes: This step requires one person to go around changing the prototypes in all xlators as required. The change is cosmetic only because the change does not require that these new arguments be interpreted by the fops. Delegated to Shehjar Deliverable: One patch per fop. This will ensure that every single changed fop will still continue to result in a successful build. 3. Logic changes in xlators: Requires the above translator delegates to start using those new arguments in the changed prototypes. Deliverable: one patchset per xlator. 4. Merge to mainline. By tomorrow(16.07, IST), the delegates will determine the time required for implementing their tasks. Based on that, Vijay will discuss how to schedule development. -Shehjar ---------- From: Amar Tumballi <amar> Date: Wed, Jul 15, 2009 at 9:01 AM To: Anand Avati <avati>, Anand Babu Periasamy <ab> Cc: dl-hacking <dl-hacking> Avati/AB, Do we need 'unify' at all in 2.1?? I think maintaining all these changes and keeping it out of bugs for a module with no users, the effort is not worth. Only reason for unify to survive 2.0.x release is, DHT was unable to provide 'switch' support properly, but with the later readdir changes, implementing a switch behavior in DHT has become very simple. Hence I propose that we should be droping unify from the code base. ---------- From: Anand Babu Periasamy <ab> Date: Wed, Jul 15, 2009 at 9:07 AM To: Amar Tumballi <amar> Cc: Anand Avati <avati>, dl-hacking <dl-hacking> I think we should drop it. If you really have a reason to have it, we should create classify it under deprecated/cluster/unify. If it doesn't work at all in 2.1 and too much work to fix it, we should drop it. -- Anand Babu Periasamy GPG Key ID: 0x62E15A31 Blog [http://unlocksmith.org] GlusterFS [http://www.gluster.org] GNU/Linux [http://www.gnu.org] ---------- From: Anand Avati <avati> Date: Wed, Jul 15, 2009 at 9:46 AM To: Shehjar Tikoo <shehjart> Cc: dl-hacking <dl-hacking> This is a good plan. What about the changes to the remaining translators? Avati ---------- From: Vijay Bellur <vijay> Date: Wed, Jul 15, 2009 at 10:05 AM To: Anand Avati <avati> Cc: Shehjar Tikoo <shehjart>, dl-hacking <dl-hacking> Anand Avati wrote: The translators that require extra functionality/logic to be added have been mentioned above. The remaining translators would have change only in prototypes and that would be done by Shehjar. Do you foresee more changes in other translators? -Vijay ---------- From: Anand Avati <avati> Date: Wed, Jul 15, 2009 at 11:51 AM To: Shehjar Tikoo <shehjart> Cc: dl-hacking <dl-hacking> Note that you would also have to change all the STACK_WIND and UNWIND invocations of those fops to pass extra dummy parameters, and make sure those dummy parameters are kept track of somehow while fixing the translators (by forcing a warning of some sort), and not get left behind in the end. To make things worse, our current STACK_UNWIND has no type check :) Avati ---------- From: Amar Tumballi <amar> Date: Wed, Jul 15, 2009 at 12:48 PM To: Anand Avati <avati> Cc: Shehjar Tikoo <shehjart>, dl-hacking <dl-hacking> Avati, and Team, I propose the idea of changing xlator.h first (for APIs), and then starting configure.ac from fresh set of translators which gets these changes properly.. least disruptive, and we have less dependency on the step 2 (that is one man job to change 1040+ STACK_WINDs, 1400+ STACK_UNWINDs, 930+ function definitions, and 1300+ fop_cbk definitions. I guess it will take minimum 14 days for one man if we start with cosmetic changes as first step. -Amar
Shehjar Tikoo wrote: > > In that case, we'll be distributing the fops among all the developers. Here is a list of who does what: Gowda Raghavendra Vikas Shehjar Avati Vijay ====================================================================== lookup ftruncate symlink fsync fgetxattr setdents stat utimens rename opendir removexattr getdents fstat access link readdir lk checksum chmod readlink create fsyncdir inodelk xattrop fchmod mknod open statfs finodelk fxattrop chown mkdir readv setxattr entrylk lock_notify fchown unlink writev getxattr fentrylk lock_fnotify truncate rmdir flush fsetxattr Thanks, Vijay
Anther attempt to make the table cleaner. <table border=1> <tr> <td>Gowda</td><td>Raghavendra</td><td>Vikas</td><td>Shehjar</td><td>Avati</td><td>Vijay</td></tr> <tr> <td>lookup</td><td>ftruncate</td><td>symlink</td><td>fsync</td><td>fgetxattr</td><td>setdents</td> </tr> <tr> <td>stat</td><td>utimens</td><td>rename</td><td>opendir</td><td>removexattr</td><td>getdents</td> </tr> <tr> <td>fstat</td><td>access</td><td>link</td><td>readdir</td><td>lk</td><td>checksum</td> </tr> <tr> <td>chmod</td><td>readlink</td><td>create</td><td>fsyncdir</td><td>inodelk</td><td>xattrop</td> </tr> <tr> <td>fchmod</td><td>mknod</td><td>open</td><td>statfs</td><td>finodelk</td><td>fxattrop</td> </tr> <tr> <td>chown</td><td>mkdir</td><td>readv</td><td>setxattr</td><td>entrylk</td><td>lock_notify</td> </tr> <tr> <td>fchown</td><td>unlink</td><td>writev</td><td>getxattr</td><td>fentrylk</td><td>lock_fnotify</td> </tr> <tr> <td>truncate</td><td>rmdir</td><td>flush</td><td>fsetxattr</td> </tr> </table> Thanks, Vijay
Ah, well, better continue referring to Vijay's email. The formatting here is crap. (In reply to comment #2) > Anther attempt to make the table cleaner. >
PATCH: http://patches.gluster.com/patch/1608 in master (Global: NFS-friendly prototype changes)
PATCH: http://patches.gluster.com/patch/1605 in master (unify: NFS-friendly logic changes)
PATCH: http://patches.gluster.com/patch/1606 in master (posix: NFS-friendly logic changes)
PATCH: http://patches.gluster.com/patch/1607 in master (server: NFS-friendly logic changes)
PATCH: http://patches.gluster.com/patch/1609 in master (client: NFS-friendly logic changes)
PATCH: http://patches.gluster.com/patch/1611 in master (trace: NFs-friendly logic changes)
PATCH: http://patches.gluster.com/patch/1610 in master (io-stats: NFS-friendly logic changes)
PATCH: http://patches.gluster.com/patch/1612 in master (locks: NFS-friendly logic changes)
PATCH: http://patches.gluster.com/patch/1613 in master (error-gen: NFS-friendly logic changes)
PATCH: http://patches.gluster.com/patch/1614 in master (stripe: NFS-friendly logic changes)
PATCH: http://patches.gluster.com/patch/1615 in master (filter: NFS-friendly logic changes)
PATCH: http://patches.gluster.com/patch/1616 in master (write-behind: NFS-friendly logic changes)
PATCH: http://patches.gluster.com/patch/1617 in master (read-ahead: NFS-friendly logic changes)
PATCH: http://patches.gluster.com/patch/1618 in master (io-threads: NFS-friendly logic changes)
PATCH: http://patches.gluster.com/patch/1619 in master (symlink-cache: NFS-friendly logic changes)
PATCH: http://patches.gluster.com/patch/1620 in master (ha: NFS-friendly logic changes)
PATCH: http://patches.gluster.com/patch/1621 in master (ha: Handle memory allocation failures)
PATCH: http://patches.gluster.com/patch/1622 in master (distribute: NFS-friendly logic changes)
PATCH: http://patches.gluster.com/patch/1670 in master (mem-pool: Include stdlib for calloc())
PATCH: http://patches.gluster.com/patch/1671 in master (core: Add rbtree based hash table)
PATCH: http://patches.gluster.com/patch/1672 in release-2.0 (mem-pool: Include stdlib for calloc())
PATCH: http://patches.gluster.com/patch/1673 in release-2.0 (core: Add rbtree based hashtable)
PATCH: http://patches.gluster.com/patch/1848 in master (posix: Ensure ENOTEMPTY return on rmdir)
PATCH: http://patches.gluster.com/patch/1865 in master (protocol/server: Set preparent and postparent in the response struct.)
PATCH: http://patches.gluster.com/patch/1888 in master (io-cache: NFS-friendly changes)
PATCH: http://patches.gluster.com/patch/2008 in master (cluster/afr: NFS-friendly logic changes)
PATCH: http://patches.gluster.com/patch/2019 in master (cluster/afr: Set local->fd in fsync.)
Err...is this really supposed to be fixed. I havent submitted nfs xlator yet. Dont we need that anymore? :)