[pnfs] pnfs/gfs2 stubs

[Frank Filz]

On Mon, 2008-05-05 at 16:23 -0400, david m. richter wrote:
> On Mon, 5 May 2008, Frank Filz wrote:
> 
> > On Fri, 2008-05-02 at 16:10 -0400, William A. (Andy) Adamson wrote:
> > > i have a patch that fixes print_ds_list. i'll submit it asap
> > 
> > Ok, I think I figured out how to fix print_ds_list, unfortunately, my
> > system is still crashing and not being very helpful. I can't get
> > anything to show up in /var/log/messages and I don't have serial console
> > set up, so all I get is the last 25 lines of log information or so. The
> > current crash is in mount.nfs process, but the stack makes no sense
> > whatsoever:
> > 
> > dump_trace
> > print_trace_address
> > print_trace_log_lvl
> > show_trace
> > dump_stack
> > 
> > That's it, no hint of a system call...
> 
> 	hm, gak.  does anything change if you don't set the ->layout_get() 
> or ->layout_return() export ops?  that is, can you see the client mount 
> and do GETDEVICELIST and GETDEVICEINFO and, thereafter, cat a file or 
> something and see it start doing layout processing, fail when nothing's 
> available, and then do a plain-vanilla READ?

That would be worth a try. I did try this change in
filelayout_initialize_mountpoint:

#ifdef REMOVED_CODE
	/* Retrieve device list from server */
	status = pnfs_callback_ops->nfs_getdevicelist(sb, fh, dlist);
	if (status)
		goto cleanup_mt;

	status = nfs4_pnfs_devlist_init(fl_mt->hlist);
	if (status)
		goto cleanup_mt;

	/* Retrieve and add all available devices */
	status = process_deviceid_list(fl_mt, fh, dlist);
	if (status)
		goto cleanup_mt;
#endif /* REMOVED_CODE */

Now it doesn't crash (as badly). When I write to a file, I do see layout
get being called, but the write ends up hanging. Need to look through
all the debug messages and piece out what went wrong. Hopefully that
will hold a clue as to what was crashing before.

Frank