Linux pNFS status meeting 08/12

Linux pNFS status meeting 08/12

[Marc Eshel]

Meeting on Thursday 08/12/10 at 9:30 AM pacific time (12:30 PM UMICH time)

Marc. 

Re: Linux pNFS status meeting 08/12

[J. Bruce Fields]

On Wed, Aug 11, 2010 at 09:42:21AM -0700, Marc Eshel wrote:
> Meeting on Thursday 08/12/10 at 9:30 AM pacific time (12:30 PM UMICH time)

I won't make it.--b.

Re: Linux pNFS status meeting 08/12

[Steve Dickson]

On 08/11/2010 01:29 PM, J. Bruce Fields wrote:
> On Wed, Aug 11, 2010 at 09:42:21AM -0700, Marc Eshel wrote:
>> Meeting on Thursday 08/12/10 at 9:30 AM pacific time (12:30 PM UMICH time)
> 
> I won't make it.--b.
ditto... 

steved.

Re: Linux pNFS status meeting 08/12

[Benny Halevy]

On Aug. 12, 2010, 2:01 +0300, Steve Dickson <SteveD@redhat.com> wrote:
> 
> 
> On 08/11/2010 01:29 PM, J. Bruce Fields wrote:
>> On Wed, Aug 11, 2010 at 09:42:21AM -0700, Marc Eshel wrote:
>>> Meeting on Thursday 08/12/10 at 9:30 AM pacific time (12:30 PM UMICH time)
>>
>> I won't make it.--b.
> ditto... 

Given the low attendance rate, shall we just skip the call this week?

Benny

> 
> steved.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux pNFS status meeting 08/12

[Andy Adamson]

[-- Attachment #1: Type: text/html, Size: 3349 bytes --]

[-- Attachment #2: pnfs-submit-patches.txt --]
[-- Type: text/plain, Size: 13684 bytes --]

Apply first (send to Trond?)
 - nfs41: prevent exchange_id from sending server-only flag
 - sunrpc: define xdr_decode_opaque_fixed (when is this first used?
		- decode_layoutget only user
 - sunrpc: don't reset buflen twice in xdr_shrink_pagelen

 - nfsd: remove duplicate NFS4_STATEID_SIZE declaration

DONE 1) pnfs Kconfig
	fs/nfs/Kconfig change for both pnfs and nfslayoutdriver

DONE 2) register/unregister pnfs module
	introduce nfs4_pnfs.h
	struct pnfs_layoutdriver_type
	struct layoutdriver_io_operations
	struct layoutdriver_policy_operations

	pnfs.h
	------
	pnfs_initialize()

	pnfs.c
	------
	pnfs_spinlock
	pnfs_modules_tbl
	static int pnfs_initialized
	pnfs_initialize()
	pnfs_register_layoutdriver
	find_pnfs
	pnfs_unregister_layoutdriver
	
	inode.c
	-------
	pnfs_initialize call

DONE 3) set/unset pnfs layoutdriver
	
	client.c
	-------
	nfs4_init_pnfs

	nfs4.h
	-----
	enum pnfs_layouttype
	FATTR4_WORD1_FS_LAYOUT_TYPES
	FATTR4_WORD2_LAYOUT_BLKSIZE ( not used )

	pnfs.c
	------
	set_pnfs_layoutdriver
	unmount_pnfs_layoutdriver

	pnfs.h
	------
	LAYOUT_NFSV4_1_MODULE_PREFIX
	macro helpers (PNFS_EXISTS_XX)

	nfs_xdr.h
	--------
	nfs_fsinfo layouttype

	nfs4proc.c
	----------
	nfs4_fsinfo_bitmap
	add FATTR4_WORD1_FS_LAYOUT_TYPES

	nfs4_xdr.c
	----------
	decode_attr_pnfstype
	and add to decode_fsinfo

DONE 4) generic deviceid cache
	pnfs.c
	------
	nfs4_alloc_init_deviceid_cache
	nfs4_init_deviceid_node
	nfs4_set_layout_deviceid
	nfs4_unset_layout_deviceid
	nfs4_find_deviceid
	nfs4_add_deviceid
	nfs4_remove_deviceid
	nfs4_free_deviceid_cache
	nfs4_put_deviceid_cache

	nfs4_pnfs.h
	-----------
	NFS4_DEVICE_ID_HASH_BITS
	NFS4_DEVICE_ID_HASH_SIZE
	NFS4_DEVICE_ID_HASH_MASK
	nfs4_deviceid_hash
	struct nfs4_deviceid_cache
	struct nfs4_deviceid
	* all the cache function declarations *

DONE 5) filelayout init/uninit_mountpoint
	nfs4filelayout.c nfs4filelayout.h introduced
	nfs4filelayoutdev.c introduced
	module stuff
		MODULE_LICENSE("GPL");
		MODULE_AUTHOR("Dean Hildebrand <dhildebz@eecs.umich.edu>");
		MODULE_DESCRIPTION("The NFSv4 file layout driver");

		module_init(nfs4filelayout_init);
		module_exit(nfs4filelayout_exit);

	filelayout_io_operations
		filelayout_initialize_mountpoint,
		filelayout_uninitialize_mountpoint,
	filelayout_type
	nfs4filelayout_init
	nfs4filelayout_exit

	filelayout_initialize_mountpoint
	filelayout_uninitialize_mountpoint

DONE 6) filelayout data server cache
	nfs4_ds_cache_lock
	nfs4_data_server_cache
	print_ds
	print_ds_list
	_data_server_lookup
	destroy_ds
	nfs4_pnfs_ds_add

DONE 7) filelayout deviceid cache
	deviceid_fmt
	nfs4_fl_free_deviceid
	nfs4_fl_free_deviceid_callback
	nfs4_pnfs_device_item_find
	

DONE 8) generic getdeviceinfo
	pnfs.c
	------
	pnfs_client_operations pnfs_ops
        nfs4_pnfs_getdeviceinfo

	nfs4proc.c
	---------
        nfs4_pnfs_getdeviceinfo
	
	pnfs.h
	-------
        nfs4_pnfs_getdeviceinfo

	nfs4xdr.c
	---------
	encode_getdeviceinfo_maxsz
	decode_getdeviceinfo_maxsz
	NFS4_enc_getdeviceinfo_sz
	NFS4_dec_getdeviceinfo_sz
	encode_getdeviceinfo
	nfs4_xdr_enc_getdeviceinfo
	decode_getdeviceinfo
	nfs4_xdr_dec_getdeviceinfo

	pnfs_xdr.h
	----------
	nfs4_pnfs_getdeviceinfo_arg
	nfs4_pnfs_getdeviceinfo_res

DONE 9) filelayout getdeviceinfo
	get_device_info
	decode_and_add_device
	decode_device
	decode_and_add_ds

10) DONE make stateid a union
	(alexandros added a union to the stateid)

	nfs4.h
	nfs4proc.c
	nfs4xdr.c
	delegation.c
	callback_proc.c
	callback_xdr.c

DONE 11) generic layout stateid
	pnfs_set_layout_stateid
	pnfs_get_layout_stateid
	pnfs_layout_from_open_stateid

DONE 12) generic layout cache header
	pnfs.c
 	-----
	BUG_ON_UNLOCKED_INO/LO
	alloc_init_layout
	pnfs_alloc_layout
	get_layout (change to get_layout_locked)
	put_layout_locked
	put_layout
	pnfs_free_layout
		[remove lseg lookup]
	pnfs_destroy_layout
	pnfs_destroy_all_layouts

	pnfs.h
	------
	lo_fail_bit
	pnfs_destroy_all_layouts
	pnfs_destroy_layout

	nfs4_pnfs.h
	-----------
	PNFS_NFS_INODE

	nfs4state.c
	-----------
	pnfs_destroy_all_layouts call

DONE 13) filelayout layout cache header
	struct nfs4_filelayout
	filelayout_alloc_layout
	filelayout_free_layout
	FILE_LO
	add to filelayout_io_operations

DONE 14) generic layoutsegment cache
	pnfs.c
	------
	has_matching_lseg
	pnfs_has_layout
	_pnfs_update_layout
	pnfs_free_layout
		[add back lseg lookup]
	init_lseg
	destroy_lseg
	put_lseg_locked
	put_lseg

	pnfs.h
	------
	2 get_lseg
	put_lseg

	nfs4_pnfs.h
	-----------
	struct pnfs_layout_segment

DONE 15) generic layoutget
	pnfs.h
	-------
	pnfs4_proc_layoutget

	nfs4.h
	------
	NFSPROC4_CLNT_PNFS_LAYOUTGET

	nfs4proc.c
	----------
	pnfs4_proc_layoutget
	_pnfs4_proc_layoutget
		note: [call to pnfs_layout_process will be a comment]
	 nfs4_pnfs_layoutget_call_ops
        nfs4_pnfs_layoutget_prepare
        nfs4_pnfs_layoutget_done
        nfs4_pnfs_layoutget_release

	nfs4xdr.c
	---------
	encode_layoutget_sz    (encode_layoutget_maxsz)
	decode_layoutget_maxsz
	NFS4_enc_layoutget_sz
	NFS4_dec_layoutget_sz
	encode_layoutget
	decode_layoutget
	nfs4_xdr_enc_layoutget
	nfs4_xdr_dec_layoutget

DONE 16) layoutget helpers
	pnfs.c
	------
	send_layout                  (send_layoutget)
		[ uncomment _pnfs_update_layout call to send_layout]
	pnfs_layout_release
	pnfs_get_layout_done
	cmp_layout 	(cmp_lseg)
	pnfs_insert_layout (pnfs_insert_lseg)
	pnfs_layout_process (pnfs_process_lseg)

DONE 17) filelayout layout segment cache
	struct nfs4_filelayout_segment

	nfs4filelayout.c
	----------------
	filelayout_alloc_lseg 
	filelayout_free_lseg
	_filelayout_free_lseg
	filelayout_free_fh_array
	filelayout_set_layout
	filelayout_check_layout

	nfs4_pnfs.h
	-----------
	LSEG_LD_DATA

DONE 18) generic layoutcommit helpers
	pnfs.c
 	------
	initialize/uninitialize (and all layoutcommit kmem cache)
	pnfs_layoutcommit_alloc
	pnfs_layoutcommit_free
	pnfs_layoutcommit_mempool in pnfs_initialize
	pnfs_need_layoutcommit
	pnfs_layoutcommit_setup
	pnfs_update_last_write

	nfs4_pnfs.h
	-----------
	has_layout
	layoutcommit_needed

DONE 19) generic layoutcommit
	pnfs_layoutcommit_inode

	pnfs.h
	------
	pnfs_layoutcommit_inode

	nfs4.h
	------
	NFSPROC4_CLNT_PNFS_LAYOUTCOMMIT

	nfs4proc.c
	---------
	pnfs4_proc_layoutcommit
	_pnfs4_proc_layoutcommit
	pnfs_layoutcommit_ops
	pnfs_layoutcommit_release
	pnfs_layoutcommit_done
	pnfs_layoutcommit_prepare
	

	nfs4xdr.c
	--------
	encode_layoutcommit_sz     (encode_layoutcommit_maxsz)
	decode_layoutcommit_maxsz
	NFS4_enc_layoutcommit_sz
	NFS4_dec_layoutcommit_sz
	encode_layoutcommit
	decode_layoutcommit
	nfs4_xdr_enc_layoutcommit
	nfs4_xdr_dec_layoutcommit

	write.c
	-------
	nfs_write_inode call to pnfs_layoutcommit_inode


DONE 21) generic layoutreturn helpers
	pnfs.c
	------
	has_layout_to_return
	_pnfs_can_return_lseg
	should_free_lseg
	pnfs_return_layout_barrier
	_pnfs_return_layout
	
DONE 22) generic layoutreturn
	pnfs.c
	------
	return_layout

	pnfs.h
	-----
	2 pnfs_return_layout
	pnfs_layout_roc_iomode

	nfs4.h
	------
	NFSPROC4_CLNT_PNFS_LAYOUTRETURN

	nfs4proc.c
	---------
	pnfs4_proc_layoutreturn
	_pnfs4_proc_layoutreturn
	nfs4_pnfs_layoutreturn_call_ops
	nfs4_pnfs_layoutreturn_release
	nfs4_pnfs_layoutreturn_done
	nfs4_pnfs_layoutreturn_prepare

	nfs4xdr.c
	--------
	encode_layoutreturn_sz     (encode_layoutreturn_maxsz)
	decode_layoutreturn_maxsz
	NFS4_enc_layoutreturn_sz
	NFS4_dec_layoutreturn_sz
	encode_layoutreturn
	decode_layoutreturn
	nfs4_xdr_enc_layoutreturn
	nfs4_xdr_dec_layoutreturn

	inode.c
	-------
	nfs4_clear_inode pnfs_return_layout call


DONE 23) add session to nfs4_sequence
	fs/nfs/nfs4_fs.h
	nfs4proc.c
	unlink.c	

DONE 24) update nfs4_async_handle_error for data server
	is_ds_only_session
	is_ds_only_client and calls in:
	nfs4_async_handle_error

DONE 25) update state renewal for data servers 
	nfs4_renew_state
	nfs41_setup_state_renewal

DONE 26) pageio helpers
	pnfs.c
	------
	pnfs_set_pg_test
	pnfs_getboundary
	pnfs_pageio_init_read
	pnfs_pageio_init_write

	nfs4_pnfs.h
	-----------
	layoutdriver_policy_operations
		add policies
	nfs_page.h
	----------
	nfs_pageio_descriptor


27) associate layout segment with nfs_page
	pagelist.c
	----------
	nfs_create_request changes
	nfs_scan_list changes
	nfs_clear_request changes
	nfs_can_coalesce_requests changes
		
	nfs_can_coalesce_requests changes
	_pnfs_clear_lseg_from_pages

	write.c
	-------
	+nfs_mark_request_nopnfs
		call in nfs_redirty_request 
	+nfs_scan_commit
	nfs_scan_list
	nfs_try_to_update_request
	nfs_setup_write_request
	nfs_writepage_setup
	nfs_flush_incompatible
	nfs_updatepage


28) filelayout policy ops
	filelayout_policy_operations
		- add to filelayout_type
	filelayout_pg_test
	filelayout_get_stripesize
		
29) filelayout i/o helpers
	nfs4_pnfs_ds_create
	nfs4_fl_prepare_ds
	_nfs4_fl_calc_j_index
	nfs4_fl_calc_ds_index
	nfs4_fl_select_ds_fh
	filelayout_get_dserver_offset
	
30) generic read
	pnfs.c
	------
	pnfs_try_to_read_data

	pnfs.h
	-------
	pnfs_try_to_read_data

	read.c
	------
	nfs_initiate_read
	pnfs_initiate_read
	nfs_read_rpcsetup call to pnfs_initiate_read
	nfs4_read_done is_ds changes

31) filelayout read
	filelayout_read_call_done
	filelayout_read_release
	filelayout_read_call_ops
	filelayout_read_pagelist

32) generic write
	pnfs.c
	------
	pnfs_try_to_write_data

	pnfs.h
	------
	pnfs_try_to_write_data

	write.c
	-------
	nfs_initiate_write
	pnfs_initiate_write	
	nfs_write_rpcsetup call to pnfs_initiate_write
	nfs_mark_request_nopnfs
		- nfs_redirty_request
	nfs4_proc_write_setup
	nfs4_write_done
	pnfs4_update_write_done

33) data server write
	nfs4.h
	------
	add NFSPROC4_CLNT_PNFS_WRITE

	nfs4proc.c
	---------
	nfs4_proc_write_setup sets NFSPROC4_CLNT_PNFS_WRITE

	nfs4xdr.c
	--------
	add PNFS_WRITE to rpc_procinfo
	NFS4_enc_dswrite_sz
	NFS4_dec_dswrite_sz
	nfs4_xdr_enc_dswrite
	nfs4_xdr_dec_dswrite

34) file layout write
	filelayout_write_call_done
	filelayout_write_release
	filelayout_write_pagelist
	filelayout_write_call_ops

35) generic commit
	pnfs.c
	------
	pnfs_try_to_commit

	pnfs.h
	------
	pnfs_try_to_commit

	write.c
	-------
	nfs_initiate_commit
	pnfs_initiate_commit
	nfs_commit_rpcsetup call to pnfs_initiate_commit
	nfs_commit_release add nfs_mark_request_nopnfs calls
	nfs4_commit_done ds changes
	nfs4_proc_commit_setup ds changes

36) data server commit
	nfs4.h
	------
	add NFSPROC4_CLNT_PNFS_COMMIT

	nfs4proc.c
	---------
	nfs4_proc_commit_setup sets NFSPROC4_CLNT_PNFS_COMMIT

	nfs4xdr.c
	--------
	add PNFS_COMMIT to rpc_procinfo
	NFS4_enc_dscommit_sz
	NFS4_dec_dscommit_sz
	nfs4_xdr_enc_dscommit
	nfs4_xdr_dec_dscommit

	

37) file layout commit
	filelayout_clone_write_data
	filelayout_commit_call_done
	filelayout_commit_call_ops
	filelayout_commit


38) layoutrecall
	callback_proc.c
	---------------
	pnfs_is_next_layout_stateid
	nfs_layoutrecall_find_inode
	recall_layout_threadargs
	pnfs_recall_layout
	pnfs_async_return_layout
	pnfs_recall_all_layouts
	pnfs_cb_layoutrecall

	callback_xdr.c
	--------------
	OP_CB_LAYOUTRECALL declaration
	decode_pnfs_layoutrecall_args


	callback.h
	----------
	struct cb_pnfs_layoutrecallargs

39)  data server recovery

	nfs4proc.c
	----------
	nfs4_recover_expired_lease changes and EXPORT
	nfs4_async_handle_error change
	nfs4_setup_sequence changes

40)  unused stuff to get rid of or leave for post-submit tree

	pnfs_get_write_status
	pnfs_get_read_status
	PNFS_LD_POLICY_OPS
	struct pnfs_devicelist

	struct pnfs_client_operations nfs_return_layout operation.

	FATTR4_WORD2_LAYOUT_BLKSIZE in nfs4.h

	[ in fs/nfs/callback.h left over from removing CB_NOTIFY_DEVICEID ]
	   struct cb_pnfs_devicenotifyitem
	   #define NFS4_DEV_NOTIFY_MAXENTRIES 10
	   struct cb_pnfs_devicenotifyargs {
	   extern unsigned pnfs_cb_devicenotify(struct cb_pnfs_devicenotifyargs *args,
-                                    void *dummy);

	include/linux/nfs4_pnfs.c
		struct pnfs_devicelist


	include/linux/nfs4.h

	enum pnfs_layouttype {
       		 LAYOUT_OSD2_OBJECTS = 2,
       		 LAYOUT_BLOCK_VOLUME = 3,
	};


	fs/nfs/inode.c: nfs_update_inode; this does nothing.
	+        * file needs layout commit, server attributes may be stale
	+        */
	+       if (layoutcommit_needed(nfsi) && nfsi->change_attr >= fattr->change_attr) {
	+               dprintk("NFS: %s: layoutcommit is needed for file %s/%ld\n",
	+                       __func__, inode->i_sb->s_id, inode->i_ino);
	+               return 0;
	+       }
	+       /*

	pnfs.h:
	+unsigned int pnfs_getiosize(struct nfs_server *server);



	write.c:
	--------

@@ -1489,6 +1612,7 @@ int nfs_write_inode(struct inode *inode, struct
writeback_control *wbc)
  */
 int nfs_wb_all(struct inode *inode)
 {
+       int ret;
        struct writeback_control wbc = {
                .sync_mode = WB_SYNC_ALL,
                .nr_to_write = LONG_MAX,
@@ -1496,7 +1620,8 @@ int nfs_wb_all(struct inode *inode)
                .range_end = LLONG_MAX,
        };

-       return sync_inode(inode, &wbc);
+       ret = sync_inode(inode, &wbc);
+       return ret;
 }

Re: Linux pNFS status meeting 08/12 canceled

[Marc Eshel]

Ok the meeting is canceled 



From:
Benny Halevy <bhalevy@panasas.com>
To:
Marc Eshel <eshel@almaden.ibm.com>
Cc:
Steve Dickson <SteveD@redhat.com>, "J. Bruce Fields" 
<bfields@fieldses.org>, linux-nfs@vger.kernel.org
Date:
08/12/2010 08:26 AM
Subject:
Re: Linux pNFS status meeting 08/12



On Aug. 12, 2010, 2:01 +0300, Steve Dickson <SteveD@redhat.com> wrote:
> 
> 
> On 08/11/2010 01:29 PM, J. Bruce Fields wrote:
>> On Wed, Aug 11, 2010 at 09:42:21AM -0700, Marc Eshel wrote:
>>> Meeting on Thursday 08/12/10 at 9:30 AM pacific time (12:30 PM UMICH 
time)
>>
>> I won't make it.--b.
> ditto... 

Given the low attendance rate, shall we just skip the call this week?

Benny

> 
> steved.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux pNFS status meeting 08/12

[Benny Halevy]

On Aug. 12, 2010, 18:42 +0300, Andy Adamson <andros@netapp.com> wrote:
> 
> On Aug 12, 2010, at 11:25 AM, Benny Halevy wrote:
> 
>> On Aug. 12, 2010, 2:01 +0300, Steve Dickson <SteveD@redhat.com> wrote:
>>>
>>>
>>> On 08/11/2010 01:29 PM, J. Bruce Fields wrote:
>>>> On Wed, Aug 11, 2010 at 09:42:21AM -0700, Marc Eshel wrote:
>>>>> Meeting on Thursday 08/12/10 at 9:30 AM pacific time (12:30 PM UMICH time)
>>>>
>>>> I won't make it.--b.
>>> ditto... 
>>
>> Given the low attendance rate, shall we just skip the call this week?
> 
> Here is what I've been up to.
> 
> 
> Following Fred's most excellent suggestion (at last Thursday's hackers pub meeting), I created a single patch (which I called 'the whole enchilada'!) containing all of the pnfs-submit branch changes, and then proceeded to slice/dice it into logical consumable patches for submission to Trond. This beats the heck out of trying to squash 281 patches together just to re-order all the functionality.
> 
> I've attached the battle plan which I'm mostly following, and which although has some detail, is not intended to be a complete list of functions etc. I update the battle plan as I go.

That looks great! Thanks!

> 
> I'm currently working on patch #27 called "associate layout segment with nfs_page" in the attachment, so the previous 26 patches mI tagged the tree before I started, and I do a git diff against the tag after each extraction to ensure that the tree is unchanged, and I compile after each patch that I extract from the 'whole enchilada'.  I should have the tree down to 40-some patches by this weeks end. The resultant tree will be unchanged from the current pnfs-submit tree, and the last patch will be all the code that is either unused or has no effect.


If you find anything you need to change (like renaming stuff, etc.)
please just send SQUASHME patches on top of the pnfs-submit branch to keep things in sync.

> 
> The subject of patch ownership was discussed during the pNFS conference call, but I have not added any authors/signers and would really like some help. There will be more work to do but we will be _much_ closer to a submission stream when I'm done. I think the first submission (this month) should be patches numbered 1-17 in the attachment which provides LAYOUTGET functionality.

As I suggested, since many of us will have contributed to the contents of most of the patches (please
excuse my poor English, I'm not sure I got the tenses right ;-)), let's set the Author: as
"The pNFS Team <linux-nfs@vger.kernel.org>" and then we can hopefully derive the sign-offs automatically
using git correlated with the respective patches line numbers.

Benny

> 
> If you want to have the call today, it's fine with me.
> 
> -->Andy
> 
> 
> 
> 
> 
>>
>> Benny
>>
>>>
>>> steved.
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Linux pNFS status meeting 08/12

[Jim Rees]

Benny Halevy wrote:

  Given the low attendance rate, shall we just skip the call this week?

I'll be around but am happy to skip it.  The only thing I wanted to bring up
was divergence between pnfs-all-latest and linux.org mainline, and plans and
timetables for pushing upstream.  I've brought this up before but was hoping
for an update.

Re: Linux pNFS status meeting 08/12

[William A. (Andy) Adamson]

On Thu, Aug 12, 2010 at 11:55 AM, Benny Halevy <bhalevy@panasas.com> wrote:
> On Aug. 12, 2010, 18:42 +0300, Andy Adamson <andros@netapp.com> wrote:
>>
>> On Aug 12, 2010, at 11:25 AM, Benny Halevy wrote:
>>
>>> On Aug. 12, 2010, 2:01 +0300, Steve Dickson <SteveD@redhat.com> wrote:
>>>>
>>>>
>>>> On 08/11/2010 01:29 PM, J. Bruce Fields wrote:
>>>>> On Wed, Aug 11, 2010 at 09:42:21AM -0700, Marc Eshel wrote:
>>>>>> Meeting on Thursday 08/12/10 at 9:30 AM pacific time (12:30 PM UMICH time)
>>>>>
>>>>> I won't make it.--b.
>>>> ditto...
>>>
>>> Given the low attendance rate, shall we just skip the call this week?
>>
>> Here is what I've been up to.
>>
>>
>> Following Fred's most excellent suggestion (at last Thursday's hackers pub meeting), I created a single patch (which I called 'the whole enchilada'!) containing all of the pnfs-submit branch changes, and then proceeded to slice/dice it into logical consumable patches for submission to Trond. This beats the heck out of trying to squash 281 patches together just to re-order all the functionality.
>>
>> I've attached the battle plan which I'm mostly following, and which although has some detail, is not intended to be a complete list of functions etc. I update the battle plan as I go.
>
> That looks great! Thanks!
>
>>
>> I'm currently working on patch #27 called "associate layout segment with nfs_page" in the attachment, so the previous 26 patches mI tagged the tree before I started, and I do a git diff against the tag after each extraction to ensure that the tree is unchanged, and I compile after each patch that I extract from the 'whole enchilada'.  I should have the tree down to 40-some patches by this weeks end. The resultant tree will be unchanged from the current pnfs-submit tree, and the last patch will be all the code that is either unused or has no effect.
>
>
> If you find anything you need to change (like renaming stuff, etc.)
> please just send SQUASHME patches on top of the pnfs-submit branch to keep things in sync.

OK. I was planning on sending you the 'new' pnfs-submit tree patchset
that left the resultant tree unchanged, and then do renames, etc on
top - just so we know where we are.

>
>>
>> The subject of patch ownership was discussed during the pNFS conference call, but I have not added any authors/signers and would really like some help. There will be more work to do but we will be _much_ closer to a submission stream when I'm done. I think the first submission (this month) should be patches numbered 1-17 in the attachment which provides LAYOUTGET functionality.
>
> As I suggested, since many of us will have contributed to the contents of most of the patches (please
> excuse my poor English, I'm not sure I got the tenses right ;-)), let's set the Author: as
> "The pNFS Team <linux-nfs@vger.kernel.org>" and then we can hopefully derive the sign-offs automatically
> using git correlated with the respective patches line numbers.

OK. I'll just add your suggested Author and then send you the tree so
you can help with the sign-offs list.

-->Andy

>
> Benny
>
>>
>> If you want to have the call today, it's fine with me.
>>
>> -->Andy
>>
>>
>>
>>
>>
>>>
>>> Benny
>>>
>>>>
>>>> steved.
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Linux pNFS status meeting 08/12

[Benny Halevy]

On Aug. 12, 2010, 18:59 +0300, "William A. (Andy) Adamson" <androsadamson@gmail.com> wrote:
> On Thu, Aug 12, 2010 at 11:55 AM, Benny Halevy <bhalevy@panasas.com> wrote:
>> On Aug. 12, 2010, 18:42 +0300, Andy Adamson <andros@netapp.com> wrote:
>>>
>>> On Aug 12, 2010, at 11:25 AM, Benny Halevy wrote:
>>>
>>>> On Aug. 12, 2010, 2:01 +0300, Steve Dickson <SteveD@redhat.com> wrote:
>>>>>
>>>>>
>>>>> On 08/11/2010 01:29 PM, J. Bruce Fields wrote:
>>>>>> On Wed, Aug 11, 2010 at 09:42:21AM -0700, Marc Eshel wrote:
>>>>>>> Meeting on Thursday 08/12/10 at 9:30 AM pacific time (12:30 PM UMICH time)
>>>>>>
>>>>>> I won't make it.--b.
>>>>> ditto...
>>>>
>>>> Given the low attendance rate, shall we just skip the call this week?
>>>
>>> Here is what I've been up to.
>>>
>>>
>>> Following Fred's most excellent suggestion (at last Thursday's hackers pub meeting), I created a single patch (which I called 'the whole enchilada'!) containing all of the pnfs-submit branch changes, and then proceeded to slice/dice it into logical consumable patches for submission to Trond. This beats the heck out of trying to squash 281 patches together just to re-order all the functionality.
>>>
>>> I've attached the battle plan which I'm mostly following, and which although has some detail, is not intended to be a complete list of functions etc. I update the battle plan as I go.
>>
>> That looks great! Thanks!
>>
>>>
>>> I'm currently working on patch #27 called "associate layout segment with nfs_page" in the attachment, so the previous 26 patches mI tagged the tree before I started, and I do a git diff against the tag after each extraction to ensure that the tree is unchanged, and I compile after each patch that I extract from the 'whole enchilada'.  I should have the tree down to 40-some patches by this weeks end. The resultant tree will be unchanged from the current pnfs-submit tree, and the last patch will be all the code that is either unused or has no effect.
>>
>>
>> If you find anything you need to change (like renaming stuff, etc.)
>> please just send SQUASHME patches on top of the pnfs-submit branch to keep things in sync.
> 
> OK. I was planning on sending you the 'new' pnfs-submit tree patchset
> that left the resultant tree unchanged, and then do renames, etc on
> top - just so we know where we are.
> 

That's even better :)
I'm back on my feet (metaphorically) now after the move
so I'm ready for your patches, feel free to throw them at me any time :)

Benny

>>
>>>
>>> The subject of patch ownership was discussed during the pNFS conference call, but I have not added any authors/signers and would really like some help. There will be more work to do but we will be _much_ closer to a submission stream when I'm done. I think the first submission (this month) should be patches numbered 1-17 in the attachment which provides LAYOUTGET functionality.
>>
>> As I suggested, since many of us will have contributed to the contents of most of the patches (please
>> excuse my poor English, I'm not sure I got the tenses right ;-)), let's set the Author: as
>> "The pNFS Team <linux-nfs@vger.kernel.org>" and then we can hopefully derive the sign-offs automatically
>> using git correlated with the respective patches line numbers.
> 
> OK. I'll just add your suggested Author and then send you the tree so
> you can help with the sign-offs list.
> 
> -->Andy
> 
>>
>> Benny
>>
>>>
>>> If you want to have the call today, it's fine with me.
>>>
>>> -->Andy
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Benny
>>>>
>>>>>
>>>>> steved.
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

Linux pNFS status meeting 08/19

[Marc Eshel]

Meeting on Thursday 08/19/10 at 9:30 AM pacific time (12:30 PM UMICH time)

Marc. 

Linux pNFS status meeting 08/26

[Marc Eshel]

Meeting on Thursday 08/26/10 at 9:30 AM pacific time (12:30 PM UMICH time)

Marc. 

Re: Linux pNFS status meeting 08/26

[Benny Halevy]

On Aug. 26, 2010, 6:32 +0300, Marc Eshel <eshel@almaden.ibm.com> wrote:
> Meeting on Thursday 08/26/10 at 9:30 AM pacific time (12:30 PM UMICH time)

Sorry, I can't make it today.
Latest status: pnfs-all-2.6.35-2010-08-24 was released with
the latest pnfs-submit branch, including Andy's renaming work
and his fix of a rcu bug in pnfs deviceid cache found by Fred.

I applied the renames onto the rest of the generic pnfs code and
layout drivers as well as renamed code for the callback path
to match the existing naming convention. I also cleaned up
the patchset itself to get it one step closer for the next step.

Right now I'm rebasing the tree onto 2.6.36-rc1 and will release
the rebased version after giving it a good test.

The next step is reorganize the patchset into shorter runs and
possibly squash together some small patches into bigger ones as
we discussed so to make it easier for review.

Benny

> 
> Marc. 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
_______________________________________________
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@vger.kernel.org.)

NFSv4 mailing list
NFSv4@linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

RE: Linux pNFS status meeting 08/26

[Labiaga, Ricardo]

Last week Andy, Fred, Trond, and I were physically in the same location,
so we took the opportunity to review the first set of patches in the
pnfs-submit branch and further discussed the best way to proceed with
the submission.  For ease of review, Trond reiterated that we submit our
patches in waves of functionality and that they be submitted as a set of
few large patches.

The proposal is to submit the functionality in the following order:

1st Layoutget and getdeviceinfo (together)
2nd Layoutreturn
3rd Read/ Write I/O path (could be broken into two sets)
4th Callback Path
5th Layoutcommit

For the 1st wave of functionality, the suggestion is to submit three
large patches:

1. Everything that touches NFS common code 
  (such as init and uninit pNFS, pnfs_update_layout invocations)
2. Layoutget and getdeviceinfo generic code common to all layout drivers
3. File layout specific layoutget and getdeviceinfo

This means we have about 19 or so of the first pnfs-submit patches that
need to be squashed into a single patch for ease of review.  In
addition, we found a number of minor issues during the review that need
to be addressed.  We also need to strip out some things that are not
strictly needed for the first wave of patches, with the intent to
reintroduce them when the functionality is actually used by objects and
blocks.  It was made clear that including functionality that is not
required by the File Layout driver at this time is not appropriate.  For
example, io_ops that are no required by the File Layout (and have a
trivial implementation) are a no-go.  The abstraction is best introduced
when the drivers that actually require it are submitted.

Andy and Fred will email the details of the changes along with the
patches shortly.

Net-net, no radical changes needed, but a number of small issues that
need to be addressed before we can start submitting.  More details
coming shortly.

Thanks,
	
- ricardo


> -----Original Message-----
> From: Benny Halevy [mailto:bhalevy@panasas.com]
> Sent: Thursday, August 26, 2010 12:40 AM
> To: Marc Eshel
> Cc: linux-nfs@vger.kernel.org; nfsv4@linux-nfs.org
> Subject: Re: Linux pNFS status meeting 08/26
> 
> On Aug. 26, 2010, 6:32 +0300, Marc Eshel <eshel@almaden.ibm.com>
wrote:
> > Meeting on Thursday 08/26/10 at 9:30 AM pacific time (12:30 PM UMICH
> time)
> 
> Sorry, I can't make it today.
> Latest status: pnfs-all-2.6.35-2010-08-24 was released with
> the latest pnfs-submit branch, including Andy's renaming work
> and his fix of a rcu bug in pnfs deviceid cache found by Fred.
> 
> I applied the renames onto the rest of the generic pnfs code and
> layout drivers as well as renamed code for the callback path
> to match the existing naming convention. I also cleaned up
> the patchset itself to get it one step closer for the next step.
> 
> Right now I'm rebasing the tree onto 2.6.36-rc1 and will release
> the rebased version after giving it a good test.
> 
> The next step is reorganize the patchset into shorter runs and
> possibly squash together some small patches into bigger ones as
> we discussed so to make it easier for review.
> 
> Benny
> 
> >
> > Marc.
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> _______________________________________________
> 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@vger.kernel.org.)
> 
> NFSv4 mailing list
> NFSv4@linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

Re: Linux pNFS status meeting 08/26

[J. Bruce Fields]

On Mon, Aug 30, 2010 at 02:15:43PM -0700, Labiaga, Ricardo wrote:
> Last week Andy, Fred, Trond, and I were physically in the same location,
> so we took the opportunity to review the first set of patches in the
> pnfs-submit branch and further discussed the best way to proceed with
> the submission.  For ease of review, Trond reiterated that we submit our
> patches in waves of functionality and that they be submitted as a set of
> few large patches.
> 
> The proposal is to submit the functionality in the following order:
> 
> 1st Layoutget and getdeviceinfo (together)
> 2nd Layoutreturn
> 3rd Read/ Write I/O path (could be broken into two sets)
> 4th Callback Path
> 5th Layoutcommit
> 
> For the 1st wave of functionality, the suggestion is to submit three
> large patches:
> 
> 1. Everything that touches NFS common code 
>   (such as init and uninit pNFS, pnfs_update_layout invocations)
> 2. Layoutget and getdeviceinfo generic code common to all layout drivers
> 3. File layout specific layoutget and getdeviceinfo

I understand large patches for the latter two, but for the first, might
it be worth keeping smaller patches?  Changes to common code seem most
at risk of breaking existing functionality.  And they might be
individually testable (since you can test for regressions), as opposed to
the new stuff that may be impossible to test until it's all applied.

But that's all just generalities--if people who've looked at the patches
don't think they split up sensibly, then fine.

--b.

Re: Linux pNFS status meeting 08/26

[Boaz Harrosh]

On 08/31/2010 12:15 AM, Labiaga, Ricardo wrote:
> Last week Andy, Fred, Trond, and I were physically in the same location,
> so we took the opportunity to review the first set of patches in the
> pnfs-submit branch and further discussed the best way to proceed with
> the submission.  For ease of review, Trond reiterated that we submit our
> patches in waves of functionality and that they be submitted as a set of
> few large patches.
> 
> The proposal is to submit the functionality in the following order:
> 
> 1st Layoutget and getdeviceinfo (together)
> 2nd Layoutreturn
> 3rd Read/ Write I/O path (could be broken into two sets)
> 4th Callback Path
> 5th Layoutcommit
> 

A natural read and understanding of pnfs has this logical progression

1st Layoutget and getdeviceinfo (together)
2rd Read/ Write I/O path (could be broken into two sets)
3rd Layoutcommit
4th Layoutreturn
5th Callback Path

Could you elaborate a bit on why you choose to reorder them this way?

> For the 1st wave of functionality, the suggestion is to submit three
> large patches:
> 

I would love to see a:
0. Complete STD definitions headers

> 1. Everything that touches NFS common code 
>   (such as init and uninit pNFS, pnfs_update_layout invocations)

Separation to proc and XDR layers

> 2. Layoutget and getdeviceinfo generic code common to all layout drivers

Is that the high level pnfs.c stuff? then YES nice.

Will this be together with it's invocation at the nfs-vfs files like
inode.c write.c etc.. ?

> 3. File layout specific layoutget and getdeviceinfo
> 

You might want to reorder 2 and 3. First submit services which are at first
dead code. Then submit the code that calls them. Are you making a point
in making each patch compilable, runnable through out?

> This means we have about 19 or so of the first pnfs-submit patches that
> need to be squashed into a single patch for ease of review.  In
> addition, we found a number of minor issues during the review that need
> to be addressed.  We also need to strip out some things that are not
> strictly needed for the first wave of patches, with the intent to
> reintroduce them when the functionality is actually used by objects and
> blocks.  It was made clear that including functionality that is not
> required by the File Layout driver at this time is not appropriate.  For
> example, io_ops that are no required by the File Layout (and have a
> trivial implementation) are a no-go.  The abstraction is best introduced
> when the drivers that actually require it are submitted.
> 
> Andy and Fred will email the details of the changes along with the
> patches shortly.
> 
> Net-net, no radical changes needed, but a number of small issues that
> need to be addressed before we can start submitting.  More details
> coming shortly.
> 
> Thanks,
> 	
> - ricardo

Thanks
Boaz

Re: Linux pNFS status meeting 08/26

[Fred Isaman]

On Tue, Aug 31, 2010 at 9:26 AM, J. Bruce Fields <bfields@fieldses.org> wro=
te:
> On Mon, Aug 30, 2010 at 02:15:43PM -0700, Labiaga, Ricardo wrote:
>> Last week Andy, Fred, Trond, and I were physically in the same location,
>> so we took the opportunity to review the first set of patches in the
>> pnfs-submit branch and further discussed the best way to proceed with
>> the submission. =A0For ease of review, Trond reiterated that we submit o=
ur
>> patches in waves of functionality and that they be submitted as a set of
>> few large patches.
>>
>> The proposal is to submit the functionality in the following order:
>>
>> 1st Layoutget and getdeviceinfo (together)
>> 2nd Layoutreturn
>> 3rd Read/ Write I/O path (could be broken into two sets)
>> 4th Callback Path
>> 5th Layoutcommit
>>
>> For the 1st wave of functionality, the suggestion is to submit three
>> large patches:
>>
>> 1. Everything that touches NFS common code
>> =A0 (such as init and uninit pNFS, pnfs_update_layout invocations)
>> 2. Layoutget and getdeviceinfo generic code common to all layout drivers
>> 3. File layout specific layoutget and getdeviceinfo
>
> I understand large patches for the latter two, but for the first, might
> it be worth keeping smaller patches? =A0Changes to common code seem most
> at risk of breaking existing functionality. =A0And they might be
> individually testable (since you can test for regressions), as opposed to
> the new stuff that may be impossible to test until it's all applied.
>

Note that the not much touches the common code, especially in our
first submission, so it will be a fairly small patch, which we will
not be adverse to breaking up at reviewers request.  Right now we are
trying to accommodate Cristoph's request for larger patches combined
with Trond's request for small, easy to review patches for anything
that touches common code.

Fred

> But that's all just generalities--if people who've looked at the patches
> don't think they split up sensibly, then fine.
>
> --b.
> _______________________________________________
> NOTE: THIS LIST IS DEPRECATED. =A0Please use linux-nfs@vger.kernel.org in=
stead.
> (To subscribe to linux-nfs@vger.kernel.org: send "subscribe linux-nfs" in=
 the body of a message to majordomo@vger.kernel.org.)
>
> NFSv4 mailing list
> NFSv4@linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
>
_______________________________________________
NOTE: THIS LIST IS DEPRECATED.  Please use linux-nfs@vger.kernel.org instea=
d.
(To subscribe to linux-nfs@vger.kernel.org: send "subscribe linux-nfs" in t=
he body of a message to majordomo@vger.kernel.org.)

NFSv4 mailing list
NFSv4@linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

Re: Linux pNFS status meeting 08/26

[Fred Isaman]

On Tue, Aug 31, 2010 at 9:58 AM, Boaz Harrosh <bharrosh@panasas.com> wrote:
> On 08/31/2010 12:15 AM, Labiaga, Ricardo wrote:
>> Last week Andy, Fred, Trond, and I were physically in the same location,
>> so we took the opportunity to review the first set of patches in the
>> pnfs-submit branch and further discussed the best way to proceed with
>> the submission. =A0For ease of review, Trond reiterated that we submit o=
ur
>> patches in waves of functionality and that they be submitted as a set of
>> few large patches.
>>
>> The proposal is to submit the functionality in the following order:
>>
>> 1st Layoutget and getdeviceinfo (together)
>> 2nd Layoutreturn
>> 3rd Read/ Write I/O path (could be broken into two sets)
>> 4th Callback Path
>> 5th Layoutcommit
>>
>
> A natural read and understanding of pnfs has this logical progression
>
> 1st Layoutget and getdeviceinfo (together)
> 2rd Read/ Write I/O path (could be broken into two sets)
> 3rd Layoutcommit
> 4th Layoutreturn
> 5th Callback Path
>
> Could you elaborate a bit on why you choose to reorder them this way?
>

Because in your suggested order, the IO code would not work correctly
until the layoutreturn code is added.  With our ordering, at each step
there is fully functional code that does not depend for correctness on
future patches.  (Note that the layoutcommit code is basically
optional for the file driver, so is last.)

>> For the 1st wave of functionality, the suggestion is to submit three
>> large patches:
>>
>
> I would love to see a:
> 0. Complete STD definitions headers
>

Trond has said that enums taken direct from the spec can include their
full definitions, even if not all are used yet, so those that we
include should be complete.

>> 1. Everything that touches NFS common code
>> =A0 (such as init and uninit pNFS, pnfs_update_layout invocations)
>
> Separation to proc and XDR layers

This will be more like what you ask about below...the invocation of
pnfs code on mount/umount, and calls to pnfs_update_layout.

>
>> 2. Layoutget and getdeviceinfo generic code common to all layout drivers
>
> Is that the high level pnfs.c stuff? then YES nice.
>

Very roughly, the pnfs.c code stripped of anything related to
LAYOUTRETURN, LAYOUTCOMMIT, or needed only for block/object drivers.

> Will this be together with it's invocation at the nfs-vfs files like
> inode.c write.c etc.. ?
>
>> 3. File layout specific layoutget and getdeviceinfo
>>
>
> You might want to reorder 2 and 3. First submit services which are at fir=
st
> dead code. Then submit the code that calls them. Are you making a point
> in making each patch compilable, runnable through out?
>

We've been told to avoid having dead code.  So any patch which
includes a function also has callers of that function.  Thus we need
to keep the ordering of 2 and 3.

Ignoring how we split up the code for our first submission for the
moment, we should be sending out the actual changes we are making to
the current first ~20 patches of pnfs-submit by the end of the day.
We'll split the code once those changes are reviewed.

Fred

>> This means we have about 19 or so of the first pnfs-submit patches that
>> need to be squashed into a single patch for ease of review. =A0In
>> addition, we found a number of minor issues during the review that need
>> to be addressed. =A0We also need to strip out some things that are not
>> strictly needed for the first wave of patches, with the intent to
>> reintroduce them when the functionality is actually used by objects and
>> blocks. =A0It was made clear that including functionality that is not
>> required by the File Layout driver at this time is not appropriate. =A0F=
or
>> example, io_ops that are no required by the File Layout (and have a
>> trivial implementation) are a no-go. =A0The abstraction is best introduc=
ed
>> when the drivers that actually require it are submitted.
>>
>> Andy and Fred will email the details of the changes along with the
>> patches shortly.
>>
>> Net-net, no radical changes needed, but a number of small issues that
>> need to be addressed before we can start submitting. =A0More details
>> coming shortly.
>>
>> Thanks,
>>
>> - ricardo
>
> Thanks
> Boaz
> _______________________________________________
> NOTE: THIS LIST IS DEPRECATED. =A0Please use linux-nfs@vger.kernel.org in=
stead.
> (To subscribe to linux-nfs@vger.kernel.org: send "subscribe linux-nfs" in=
 the body of a message to majordomo@vger.kernel.org.)
>
> NFSv4 mailing list
> NFSv4@linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
>
_______________________________________________
NOTE: THIS LIST IS DEPRECATED.  Please use linux-nfs@vger.kernel.org instea=
d.
(To subscribe to linux-nfs@vger.kernel.org: send "subscribe linux-nfs" in t=
he body of a message to majordomo@vger.kernel.org.)

NFSv4 mailing list
NFSv4@linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

Re: Linux pNFS status meeting 08/26

[Christoph Hellwig]

On Tue, Aug 31, 2010 at 10:51:11AM -0700, Fred Isaman wrote:
> Note that the not much touches the common code, especially in our
> first submission, so it will be a fairly small patch, which we will
> not be adverse to breaking up at reviewers request.  Right now we are
> trying to accommodate Cristoph's request for larger patches combined
> with Trond's request for small, easy to review patches for anything
> that touches common code.

I'm not Cristoph, but for changes to generic code anywhere in the kernel
small patches are indeed a requirement, adn they should do exactly one
thing.  Adding new code is a different issue from that.