On Jun. 07, 2009, 11:51 +0300, Benny Halevy <bhalevy@xxxxxxxxxxx> wrote: > On Jun. 04, 2009, 15:31 +0300, Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: >> On 06/04/2009 11:51 AM, Fred Isaman wrote: >>> People were having problems with the fedora RPMs, and investigation >>> shows that the problem is related to the fact that CONFIG_NFS_FS is >>> set to "m" while CONFIG_PNFS_BLOCK is set to "y". In this case the >>> driver never registers (via module_init) with the NFS code. The >>> problem is fixed by setting CONFIG_PNFS_BLOCK to "m". >>> >>> Is there anyway (simple) way this could be expected to work? Because >>> as is, my understanding is that the block-layout tries to register >>> with (the yet unloaded) NFS module, and once the NFS module is loaded, >>> the block-layout code is never called again. >>> >>> Steve, would it be possible in the meantime to change to "CONFIG_PNFS_BLOCK=m"? >>> >>> Benny, does the PANLAYOUT driver have the same problem? > > I believe so. When I try to configure panlayout as 'y' rather than 'm' > it looks like it does not even link properly with neither the nfs module > nor the kernel. FWIW, When both CONFIG_NFS_FS and CONFIG_PNFS_PANLAYOUT are set to 'y' it does get linked properly with the kernel... Benny > >>> Fred >> >> Below little trick will default the layout driver to be the same as the CONFIG_NFS_FS >> that is if CONFIG_NFS_FS=y then CONFIG_PNFS_BLOCK will be y and so for =m. >> >> config PNFS_OBJLAYOUT >> tristate "Provide a pNFS block client (EXPERIMENTAL)" >> depends on NFS_FS && PNFS >> help >> Say M or Y here if you want your pNfs client to support the block protocol. >> Note if CONFIG_NFS_FS==M then this must also be ==M. >> >> User can select them apart manually but if CONFIG_NFS_FS changes then CONFIG_PNFS_BLOCK >> will automatically change also. Only by first changing CONFIG_NFS_FS then manually >> changing CONFIG_PNFS_BLOCK they can separate. In which case the prompt should warn about >> CONFIG_NFS_FS=m CONFIG_PNFS_BLOCK=y does not work. >> (Experiment with this in make xconfig and see) >> >> --- >> This works because Kconfig is not very recursive. the dependency chain figures out that >> CONFIG_PNFS_BLOCK is eventually dependent on CONFIG_NFS_FS, but the default value is taken >> from the direct parent which is CONFIG_PNFS, which is "bool", therefor the =Y default. >> Above though redundant for dependency will select the correct default value dependent >> on the NFS setting. >> >> I'll send a patch upstream > > Thanks! > Besides a short term work around I think we may want to rethink the way > layout drivers are being used... > > Today the layout driver registers its layout type and it must be explicitly > loaded to do that, so you may need to manually modprobe it to get it to work. > Thereafter, the admin / user has no choice or control when to use on a > per-filesystem basis. It's all or nothing. > > I think that a more practical way would be to identify the layout driver > as a mount option and then dynamically discover and load it at mount time. > With this mechanism we can also have a default setting for this mount > option to be layout=auto, in which case, the nfs client will load predefined > layout drivers it knows about, based on the layout type attribute it sees > in run time. layout=none will disable pnfs for this mount. > > Benny > >> Boaz >> >> _______________________________________________ >> pNFS mailing list >> pNFS@xxxxxxxxxxxxx >> http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs > _______________________________________________ > pNFS mailing list > pNFS@xxxxxxxxxxxxx > http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs -- 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
