From: "J. Bruce Fields" <bfields@fieldses.org>
To: Harald Dunkel <harald.dunkel@aixigo.de>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: NFS service inside a container
Date: Fri, 11 Jul 2014 16:15:03 -0400 [thread overview]
Message-ID: <20140711201503.GC11931@fieldses.org> (raw)
In-Reply-To: <539B0683.3020605@aixigo.de>
On Fri, Jun 13, 2014 at 04:11:15PM +0200, Harald Dunkel wrote:
> Hi folks,
>
> I would like to run an NFServer inside a container. The idea
> is to mirror the whole NFS service container to a fallback
> host using drbd, and to provide preconfigured NFS containers
> to whoever needs it.
>
> Unfortunately the kernel (3.14 of Debian Jessie, backported to
> Wheezy) did not share my enthusiasm:
>
> Jun 13 15:33:55 srvl011a kernel: [ 725.372466] WARNING: CPU: 6 PID: 11134 at /build/linux-v1L7fI/linux-3.14.4/fs/nfsd/nfs4recover.c:1195 nfsd4_umh_cltrack_init+0x42/0x50 [nfsd]()
> Jun 13 15:33:55 srvl011a kernel: [ 725.372468] NFSD: attempt to initialize umh client tracking in a container!
> Jun 13 15:33:55 srvl011a kernel: [ 725.376800] Modules linked in: veth sha256_ssse3 sha256_generic hmac drbd lru_cache libcrc32c nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc bonding bridge stp llc dm_crypt ioatdma radeon iTCO_wdt iTCO_vendor_support i5400_edac lpc_ich mfd_core rng_core ttm edac_core i2c_i801 i5k_amb coretemp drm_kms_helper psmouse shpchp serio_raw joydev pcspkr evdev drm parport_pc parport processor button kvm tpm_tis tpm thermal_sys ext4 crc16 mbcache jbd2 crc32c btrfs xor raid6_pq dm_mod hid_generic usbhid hid sd_mod crct10dif_generic crc_t10dif crct10dif_common sg sr_mod cdrom ata_generic ehci_pci ata_piix uhci_hcd ehci_hcd libata usbcore e1000e usb_common igb i2c_algo_bit i2c_core dca ptp pps_core 3w_9xxx scsi_mod
> Jun 13 15:33:55 srvl011a kernel: [ 725.376868] CPU: 6 PID: 11134 Comm: rpc.nfsd Tainted: G W I 3.14-0.bpo.1-amd64 #1 Debian 3.14.4-1~bpo70+1
> Jun 13 15:33:55 srvl011a kernel: [ 725.376870] Hardware name: Supermicro X7DW3/X7DWN+, BIOS 1.2 11/04/2008
> Jun 13 15:33:55 srvl011a kernel: [ 725.376872] 0000000000000000 ffffffffa0740758 ffffffff814eb7c7 ffff8810278cbd78
> Jun 13 15:33:55 srvl011a kernel: [ 725.376875] ffffffff81064cc7 ffff880fecbeac00 ffff880febfc0100 ffff880febfc0100
> Jun 13 15:33:55 srvl011a kernel: [ 725.376878] ffff880fecbeac00 0000000000000000 ffffffff81064db5 ffffffffa0740710
> Jun 13 15:33:55 srvl011a kernel: [ 725.376881] Call Trace:
> Jun 13 15:33:55 srvl011a kernel: [ 725.376889] [<ffffffff814eb7c7>] ? dump_stack+0x41/0x51
> Jun 13 15:33:55 srvl011a kernel: [ 725.376894] [<ffffffff81064cc7>] ? warn_slowpath_common+0x87/0xc0
> Jun 13 15:33:55 srvl011a kernel: [ 725.376896] [<ffffffff81064db5>] ? warn_slowpath_fmt+0x45/0x50
> Jun 13 15:33:55 srvl011a kernel: [ 725.376902] [<ffffffffa073a652>] ? nfsd4_umh_cltrack_init+0x42/0x50 [nfsd]
> Jun 13 15:33:55 srvl011a kernel: [ 725.376907] [<ffffffffa073b5b1>] ? nfsd4_client_tracking_init+0x91/0x130 [nfsd]
> Jun 13 15:33:55 srvl011a kernel: [ 725.376914] [<ffffffffa073590d>] ? nfs4_state_start_net+0x27d/0x320 [nfsd]
> Jun 13 15:33:55 srvl011a kernel: [ 725.376919] [<ffffffffa070fae3>] ? nfsd_svc+0x1b3/0x360 [nfsd]
> Jun 13 15:33:55 srvl011a kernel: [ 725.376924] [<ffffffffa07108b0>] ? write_filehandle+0x230/0x230 [nfsd]
> Jun 13 15:33:55 srvl011a kernel: [ 725.376927] [<ffffffff812a008b>] ? simple_strtoull+0x2b/0x50
> Jun 13 15:33:55 srvl011a kernel: [ 725.376932] [<ffffffffa07108b0>] ? write_filehandle+0x230/0x230 [nfsd]
> Jun 13 15:33:55 srvl011a kernel: [ 725.376936] [<ffffffffa0710925>] ? write_threads+0x75/0xc0 [nfsd]
> Jun 13 15:33:55 srvl011a kernel: [ 725.376941] [<ffffffff81131fa9>] ? __get_free_pages+0x9/0x50
> Jun 13 15:33:55 srvl011a kernel: [ 725.376946] [<ffffffff811bd061>] ? simple_transaction_get+0xc1/0xe0
> Jun 13 15:33:55 srvl011a kernel: [ 725.376951] [<ffffffffa07108b0>] ? write_filehandle+0x230/0x230 [nfsd]
> Jun 13 15:33:55 srvl011a kernel: [ 725.376955] [<ffffffffa0710116>] ? nfsctl_transaction_write+0x56/0x80 [nfsd]
> Jun 13 15:33:55 srvl011a kernel: [ 725.376959] [<ffffffff81198026>] ? vfs_write+0xc6/0x1f0
> Jun 13 15:33:55 srvl011a kernel: [ 725.376962] [<ffffffff8119851b>] ? SyS_write+0x4b/0xb0
> Jun 13 15:33:55 srvl011a kernel: [ 725.376965] [<ffffffff814f9779>] ? system_call_fastpath+0x16/0x1b
> Jun 13 15:33:55 srvl011a kernel: [ 725.376967] ---[ end trace a408a046f76bfc25 ]---
> Jun 13 15:33:55 srvl011a kernel: [ 725.377001] ------------[ cut here ]------------
>
>
> I have found a thread on lkml about this (http://lkml.org/lkml/2013/3/1/78),
> but it seems there was no conclusion.
>
> Is this something that could be supported?
Yeah, we should really get that fixed. It can probably be worked around
by reverting to the old reboot recovery method.
--b.
next prev parent reply other threads:[~2014-07-11 20:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-13 14:11 NFS service inside a container Harald Dunkel
2014-07-11 20:15 ` J. Bruce Fields [this message]
2014-07-15 7:46 ` Harald Dunkel
2014-07-15 7:56 ` Harald Dunkel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140711201503.GC11931@fieldses.org \
--to=bfields@fieldses.org \
--cc=harald.dunkel@aixigo.de \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.