Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
Hi Chris, The reason seems that one needs a modprobe config like this (Tigran told me the trick today): alias nfs-layouttype4-1 nfs_layout_nfsv41_files alias nfs-layouttype4-2 nfs_layout_osd2_objects alias nfs-layouttype4-3 off With dCache it already works with the first line, any 2 and 3 set to off. No idea any what the 3rd type actually is, neither whether type 2 is implemented in Linux at all. Ben, I guess nfs-common would be the right package for such a file, right? you should perhaps file a bug report againt nfs-common then? Presumably these lines don't harm when NFS4.1 is not active? Cheers, Stefan -- PD Stefan Kluth, PhD - Wissenschaftler - - MPI fuer Physik - phone: +49 89 32354 468 - ATLAS - - Foehringer Ring 6 - fax:+49 89 32354 305 - OPAL - -- D-80805 Munich, Germany -- e-mail: skl...@mppmu.mpg.de - -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.00.1108181909500.20...@lapkluth2.mppmu.mpg.de
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
Hi Stefan. On Thu, 2011-08-18 at 19:13 +0200, Stefan Kluth wrote: you should perhaps file a bug report againt nfs-common then? Presumably these lines don't harm when NFS4.1 is not active? I have already,... but due to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638045 my locally generated mail is currently not delivered ^^ Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
On Wed, Aug 17, 2011 at 08:07:54PM +0200, Christoph Anton Mitterer wrote: Hi Paul. Nice to meet you here, it's a small world ;) Good to see this enabled in Debian by default, however, this alone seems to be not enough. Whenever I tried this with dCache, I could mount a remoute pnfs, listing worked, but when reading/writing I got IO errors. The reason seems that one needs a modprobe config like this (Tigran told me the trick today): alias nfs-layouttype4-1 nfs_layout_nfsv41_files alias nfs-layouttype4-2 nfs_layout_osd2_objects alias nfs-layouttype4-3 off [...] Ben, I guess nfs-common would be the right package for such a file, right? If these module aliases are actually needed (I'll have to check this) then they should be defined in the modules themselves. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110818191740.gu29...@decadent.org.uk
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
On Thu, 2011-08-18 at 20:17 +0100, Ben Hutchings wrote: The reason seems that one needs a modprobe config like this (Tigran told me the trick today): alias nfs-layouttype4-1 nfs_layout_nfsv41_files alias nfs-layouttype4-2 nfs_layout_osd2_objects alias nfs-layouttype4-3 off [...] Ben, I guess nfs-common would be the right package for such a file, right? If these module aliases are actually needed (I'll have to check this) then they should be defined in the modules themselves. Well at least it didn't work without them. I'll mail (off list) you a test server that you can mount, to verify this. Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
Hi Paul. Nice to meet you here, it's a small world ;) Good to see this enabled in Debian by default, however, this alone seems to be not enough. Whenever I tried this with dCache, I could mount a remoute pnfs, listing worked, but when reading/writing I got IO errors. The reason seems that one needs a modprobe config like this (Tigran told me the trick today): alias nfs-layouttype4-1 nfs_layout_nfsv41_files alias nfs-layouttype4-2 nfs_layout_osd2_objects alias nfs-layouttype4-3 off With dCache it already works with the first line, any 2 and 3 set to off. No idea any what the 3rd type actually is, neither whether type 2 is implemented in Linux at all. Ben, I guess nfs-common would be the right package for such a file, right? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
Hi Ben, On Thursday 21 July 2011 01:01:19 Ben Hutchings wrote: [...] How about we start by enabling NFSv4.1 starting with release candidates for Linux 3.1, and see what feedback we get for that? That sounds OK, I guess, but it does introduce a significant delay. BTW, will the release candidates be available from experimental or from a separate repository? Cheers, Paul. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201107211213.13684.paul.mil...@desy.de
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
On Thu, 2011-07-21 at 12:13 +0200, Paul Millar wrote: Hi Ben, On Thursday 21 July 2011 01:01:19 Ben Hutchings wrote: [...] How about we start by enabling NFSv4.1 starting with release candidates for Linux 3.1, and see what feedback we get for that? That sounds OK, I guess, but it does introduce a significant delay. Linux 3.1-rc1 should be out in 3 weeks or less. BTW, will the release candidates be available from experimental or from a separate repository? experimental. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
Hi Ben, On Thursday 21 July 2011 12:51:11 Ben Hutchings wrote: On Thu, 2011-07-21 at 12:13 +0200, Paul Millar wrote: [..] but it does introduce a significant delay. Linux 3.1-rc1 should be out in 3 weeks or less. Ah! OK, that's not too bad. I thought it would be longer. BTW, will the release candidates be available from experimental or from a separate repository? experimental. Great, I'll try deploying 3.1-rc1 when it becomes available. Cheers, Paul. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201107211412.23371.paul.mil...@desy.de
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
On Mon, 2011-07-18 at 17:09 +0200, Paul Millar wrote: Hi Ben, Thanks for the update. On Friday 15 July 2011 16:32:41 Ben Hutchings wrote: No news. The question remains, what the cost may be to other NFS users. Certainly NFS v4.1 is not a minor change, and it adds a lot of new code to the nfs module. I guess the question is how do we go forward here? If the stumbling block is the fear of breaking something, how do we assess the risk involved against the potential benefits? One way would be to simply test it: just roll out an updated kernel to sid. This would allow people to complain if it breaks NFS support (if the code is broken then it needs to be fixed and the sooner the better). Perhaps another approach would be to provide an additional kernel package with NFS v4.1 support built-in and ask for feedback from people (either directly or perhaps via popcon). If it helps, I can provide some tests against NFS v4.1 and NFS v4.0 servers. It's really too much trouble to do that sort of thing for every feature we might consider enabling. How about we start by enabling NFSv4.1 starting with release candidates for Linux 3.1, and see what feedback we get for that? A third possibility would be to wait until other distros (e.g., RHEL) have enabled NFS v4.1 support and see if there is a corresponding increase in NFS support tickets. [...] As I said, RHEL 6 has it - but bug reports for RHEL 6 are mostly hidden. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
Hi Ben, Thanks for the update. On Friday 15 July 2011 16:32:41 Ben Hutchings wrote: No news. The question remains, what the cost may be to other NFS users. Certainly NFS v4.1 is not a minor change, and it adds a lot of new code to the nfs module. I guess the question is how do we go forward here? If the stumbling block is the fear of breaking something, how do we assess the risk involved against the potential benefits? One way would be to simply test it: just roll out an updated kernel to sid. This would allow people to complain if it breaks NFS support (if the code is broken then it needs to be fixed and the sooner the better). Perhaps another approach would be to provide an additional kernel package with NFS v4.1 support built-in and ask for feedback from people (either directly or perhaps via popcon). If it helps, I can provide some tests against NFS v4.1 and NFS v4.0 servers. A third possibility would be to wait until other distros (e.g., RHEL) have enabled NFS v4.1 support and see if there is a corresponding increase in NFS support tickets. Do any of these approaches make sense? Do you have an alternative way of assessing the risk? I had a look at what RH is doing with this and noticed that in RHEL 6 they only enabled it for x86_64. This does suggest that it may be too expensive for smaller systems, but maybe it's just a random choice. It could be that, due to the high availability of x86_64-based machines, it's this platform that's been most tested during the NFS Connectathon events .. or, as you say, it might just be a random choice :-) Cheers, Paul. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201107181709.30907.paul.mil...@desy.de
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
On Wed, 2011-07-13 at 15:27 +0200, Paul Millar wrote: Hi Ben, On Monday 23 May 2011 18:48:56 Ben Hutchings wrote: [wishlist: NFS-4.1 / pNFS support] Anyway, I have no objection to enabling this unless it is likely to cause regressions for other NFS users. Is there any news on enabling NFS v4.1? Can I do anything to help? No news. The question remains, what the cost may be to other NFS users. Certainly NFS v4.1 is not a minor change, and it adds a lot of new code to the nfs module. I had a look at what RH is doing with this and noticed that in RHEL 6 they only enabled it for x86_64. This does suggest that it may be too expensive for smaller systems, but maybe it's just a random choice. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
Hi Ben, On Monday 23 May 2011 18:48:56 Ben Hutchings wrote: [wishlist: NFS-4.1 / pNFS support] Anyway, I have no objection to enabling this unless it is likely to cause regressions for other NFS users. Is there any news on enabling NFS v4.1? Can I do anything to help? Cheers, Paul. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201107131527.39897.paul.mil...@desy.de
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
Hi Ben, On Monday 23 May 2011 18:48:56 Ben Hutchings wrote: I believe this is a major effect on the usability of a package, without rendering it completely unusable to everyone. [...] Well, not really. I agree this is an important feature, but generally feature requests are still 'wishlist'. The only exception is for missing hardware support which can be 'important'. Sorry, me bad. I think Bastian has already reclassified this bug as a 'wishlist'. Anyway, I have no objection to enabling this unless it is likely to cause regressions for other NFS users. Thanks. There should be no direct effect: one has to specify the option minorversion=1 before nfs-utils will attempt to mount with NFS v4.1. Without this option then NFS v4 would be attempted (if the server supports v4). I normally pull all my updates from sid; but if you let me know when there's a new kernel in experimental then I can test it, if that's any help. Cheers, Paul. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201105241743.48645.paul.mil...@desy.de
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
Package: linux-2.6 Version: 2.6.39-1 Severity: important Recent kernels include support for NFS v4.1. More recently still, the kernel has included support for NFS v4.1's parallel NFS or pNFS. These options (CONFIG_NFS_V4_1 and CONFIG_PNFS_FILE_LAYOUT) may be built as modules, so are loaded on demand. Current Debain Linux kernels are build with neither option enabled (the PNFS one is even missing from the config file). Please adjust the debian build to include building NFS v4.1 and PNFS support. -- Package-specific info: ** Version: Linux version 2.6.39-1-686-pae (Debian 2.6.39-1) (m...@debian.org) (gcc version 4.4.6 (Debian 4.4.6-3) ) #1 SMP Fri May 20 20:40:05 UTC 2011 ** Command line: BOOT_IMAGE=/vmlinuz-2.6.39-1-686-pae root=UUID=9e0c7535-1e7d-46a4-ac3c-c161f64c9ed7 ro quiet ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: [5.873816] [drm] nouveau :01:00.0: 4: 0x0213: type 0x13 idx 4 tag 0xff [5.873825] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xE195 [5.873891] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE4C6 [5.887020] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xEA4D [5.887045] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xEBC8 [5.888170] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xED7A [5.908938] [drm] nouveau :01:00.0: 1 available performance level(s) [5.908946] [drm] nouveau :01:00.0: 0: memory 648MHz core 450MHz fanspeed 100% [5.908958] [drm] nouveau :01:00.0: c: memory 391MHz core 199MHz [5.909133] [TTM] Zone kernel: Available graphics memory: 432514 kiB. [5.909137] [TTM] Zone highmem: Available graphics memory: 1679940 kiB. [5.909140] [TTM] Initializing pool allocator. [5.909164] [drm] nouveau :01:00.0: Detected 256MiB VRAM [5.921467] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [5.921589] [drm] nouveau :01:00.0: Saving VGA fonts [5.986997] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [5.987002] [drm] No driver support for vblank timestamp query. [5.988542] [drm] nouveau :01:00.0: Setting dpms mode 3 on vga encoder (output 0) [5.988548] [drm] nouveau :01:00.0: Setting dpms mode 3 on vga encoder (output 1) [5.988552] [drm] nouveau :01:00.0: Setting dpms mode 3 on tmds encoder (output 2) [5.988556] [drm] nouveau :01:00.0: Setting dpms mode 3 on TV encoder (output 3) [6.009375] usbcore: registered new interface driver snd-usb-audio [6.092750] HDA Intel :00:1b.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [6.092812] HDA Intel :00:1b.0: irq 47 for MSI/MSI-X [6.092845] HDA Intel :00:1b.0: setting latency timer to 64 [6.188750] input: HDA Intel Line In at Ext Rear Jack as /devices/pci:00/:00:1b.0/sound/card0/input7 [6.188961] input: HDA Intel Mic at Ext Front Jack as /devices/pci:00/:00:1b.0/sound/card0/input8 [6.189145] input: HDA Intel Mic at Ext Rear Jack as /devices/pci:00/:00:1b.0/sound/card0/input9 [6.189327] input: HDA Intel Mic at Ext Rear Jack as /devices/pci:00/:00:1b.0/sound/card0/input10 [6.189507] input: HDA Intel Line In at Ext Rear Jack as /devices/pci:00/:00:1b.0/sound/card0/input11 [6.189690] input: HDA Intel Line Out at Ext Rear Jack as /devices/pci:00/:00:1b.0/sound/card0/input12 [6.189873] input: HDA Intel HP Out at Ext Front Jack as /devices/pci:00/:00:1b.0/sound/card0/input13 [6.261903] [drm] nouveau :01:00.0: allocated 1280x1024 fb: 0x49000, bo f71acc00 [6.262024] fbcon: nouveaufb (fb0) is primary device [6.276703] [drm] nouveau :01:00.0: Setting dpms mode 0 on vga encoder (output 0) [6.276709] [drm] nouveau :01:00.0: Output VGA-1 is running on CRTC 0 using output A [6.287539] [drm] nouveau :01:00.0: 0xD550: Parsing digital output script table [6.337176] [drm] nouveau :01:00.0: Setting dpms mode 0 on tmds encoder (output 2) [6.337180] [drm] nouveau :01:00.0: Output DVI-I-1 is running on CRTC 1 using output A [6.339885] Console: switching to colour frame buffer device 160x64 [6.342917] fb0: nouveaufb frame buffer device [6.342920] drm: registered panic notifier [6.342928] [drm] Initialized nouveau 0.0.16 20090420 for :01:00.0 on minor 0 [7.601562] Adding 3903756k swap on /dev/sda6. Priority:-1 extents:1 across:3903756k [7.958095] EXT3-fs (sda3): using internal journal [8.067662] loop: module loaded [8.107202] Disabling lock debugging due to kernel taint [8.147156] vboxdrv: Found 2 processor cores. [8.147268] vboxdrv: fAsync=0 offMin=0x843 offMax=0x1914 [8.147327] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'. [8.147330] vboxdrv: Successfully loaded version 4.0.4_OSE (interface
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
severity 627655 wishlist thanks On Mon, May 23, 2011 at 10:35:57AM +0200, Paul Millar wrote: Severity: important Please specify, why this is appropriate. Current Debain Linux kernels are build with neither option enabled (the PNFS one is even missing from the config file). Noone requested it yet. Bastian -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110523101659.gb21...@wavehammer.waldi.eu.org
Processed: Re: Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
Processing commands for cont...@bugs.debian.org: severity 627655 wishlist Bug #627655 [linux-2.6] linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support Severity set to 'wishlist' from 'important' thanks Stopping processing here. Please contact me if you need assistance. -- 627655: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627655 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.130614583213607.transcr...@bugs.debian.org
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
Hi Bastian, On Monday 23 May 2011 12:17:00 Bastian Blank wrote: severity 627655 wishlist thanks On Mon, May 23, 2011 at 10:35:57AM +0200, Paul Millar wrote: Severity: important Please specify, why this is appropriate. Sure. Some scientific communities require access to huge amounts of storage (in WLCG, the current largest sites are ~10 PB; there thousands of sites spread across the world). Traditionally, this has been the high-energy partial physics community; however, increasingly, other communities are analysing more data than can fit on (or pass through) a single server. Previous versions of NFS assumed the data was available from the same server as the filesystem metadata: there was a single NFS server that one mounts. This approach simply doesn't scale to the high-capacity / high-throughput needed by scientific analysis. Therefore, until recently, the only scalable solution was linking against custom libraries that implement proprietary protocols. These libraries provided the required throughput but are non-standard and tend to be tuned for specific storage software. You can see one such library here: http://packages.debian.org/sid/libdcap1 there are several others. Providing custom libraries has worked for scientific communities that use custom analysis software. Such user-communities have the flexibility to link their software against a custom library and access their data through the POSIX-like layer provided by the custom library. Increasingly, new scientific communities are using software that they either don't want to, or can't, modify. This means that they cannot use the existing solution of linking against a custom library; instead, their IO must go through the standard filesystem. With the provision of NFS v4.1 / pNFS, the Linux kernel allows site-admins to mount these large storage systems. This allows user-communities access to large storage with normal POSIX IO and without using any custom library. Without out NFS v4.1 / pNFS, some users are simply unable to take advantage of the large storage facilities that already exist. Without support for NFS v4.1 / pNFS in a Debian kernel, sites offering large storage for their users are forced to hand-compile their kernels, with the options enabled. I believe this is a major effect on the usability of a package, without rendering it completely unusable to everyone. Current Debain Linux kernels are build with neither option enabled (the PNFS one is even missing from the config file). Noone requested it yet. OK, I'm the first then :-) Cheers, Paul. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201105231503.34301.paul.mil...@desy.de
Bug#627655: linux-image-2.6.39-1-686-pae: missing NFS4.1 / pNFS support
On Mon, 2011-05-23 at 15:03 +0200, Paul Millar wrote: Hi Bastian, On Monday 23 May 2011 12:17:00 Bastian Blank wrote: severity 627655 wishlist thanks On Mon, May 23, 2011 at 10:35:57AM +0200, Paul Millar wrote: Severity: important Please specify, why this is appropriate. Sure. [...] I believe this is a major effect on the usability of a package, without rendering it completely unusable to everyone. [...] Well, not really. I agree this is an important feature, but generally feature requests are still 'wishlist'. The only exception is for missing hardware support which can be 'important'. Anyway, I have no objection to enabling this unless it is likely to cause regressions for other NFS users. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
