Nullfs leaks i-nodes
I created a PR, kern/178238, on this but would like to know if anyone has any ideas or patches? Have updated the system where I see this to FreeBSD 9.1-STABLE #0 r250229 and still have the problem. /glz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: /usr/src over NFS: buildworld fail
Andrew Romanenko wrote:
> On 05/02/2013 01:30 AM, Rick Macklem wrote:
> > Andrew Romanenko wrote:
> >> On 04/30/2013 02:51 AM, Jeremy Chadwick wrote:
> >>> On Mon, Apr 29, 2013 at 09:42:06PM +0300, Andrew Romanenko wrote:
> Hi everyone!
> /usr/src imported via NFS
> make buildworld is always fails in the same place with error:
> "make: result too large".
> Localy its works fine
> Does anybody know how to fix it?
>
> i386 FreeBSD 9-STABLE (r250044)
> >>> Actual output would have been more useful than a paraphrased
> >>> response.
> >>> The same goes for actual NFS server and client details (OS,
> >>> backing
> >>> filesystems, make.conf, src.conf, rc.conf, loader.conf,
> >>> sysctl.conf,
> >>> etc.).
> >>>
> >>> "Result too large" is error ERANGE (see /usr/include/errno.h),
> >>> errno
> >>> 34,
> >>> assuming that it has a capital "R" ("Result", not "result").
> >>>
> >>> I see no cases in src/usr.bin/make/* where ERANGE or errno 34 is
> >>> returned directly.
> >>>
> >>> I do not believe NFS returns ERANGE either.
> >>>
> >>> There may be cases where the backing filesystem (i.e. the
> >>> filesystem
> >>> used on the NFS server) could return ERANGE. I know ZFS does, but
> >>> only
> >>> in one specific case (only if the compression property is
> >>> enabled).
> >>> I do see some other cases in the ZFS code pertaining to UTF-8
> >>> support
> >>> that can return ERANGE but did not look at what those cases may
> >>> be.
> >>>
> >>> You may end up having to do the following:
> >>>
> >>> rm -fr /usr/obj/*
> >>> cd /usr/src
> >>> ktrace -t+ -f /tmp/ktrace.out make buildworld
> >>> {wait until the failure}
> >>> cd /tmp
> >>> kdump
> >>>
> >>> Then look to see what syscall/operation returns this. You may have
> >>> to
> >>> put this file up on the web somewhere (it should gzip quite well),
> >>> and
> >>> be aware there may be personal information in it (environment
> >>> variables,
> >>> contents of files, etc.), so choose wisely.
> >>>
> >>> Good luck.
> >>>
> >> Fixed. Trouble was in Linux NFS-server.
> >> Also, thx Jeremy for the tip (ktrace + kdump)
> >> thanks, everyone
> >>
> > Coule you please provide more information on the Linux NFS-server
> > issue?
> > It might be useful if/when others run into interoperability
> > problems against a Linux NFS server.
> >
> > Thanks, rick
> >
> >> ___
> >> freebsd-stable@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >> To unsubscribe, send any mail to
> >> "freebsd-stable-unsubscr...@freebsd.org"
> Server: Linux Sabayon
> (Linux localhost.localdomain 3.8.0-sabayon #1 SMP Fri Mar 29 13:54:24
> UTC 2013 i686 Genuine Intel(R) CPU T2080 @ 1.73GHz GenuineIntel
> GNU/Linux)
> Package: net-fs/nfs-utils-1.2.7
>
> /etc/exports
> /home/bsd/src
> 192.168.56.1/24(rw,async,no_subtree_check,root_squash,anonuid=1000,anongid=1001,fsid=1000)
>
> Client: Freebsd 9-STABLE
> (FreeBSD ion.uabsd.org 9.1-STABLE FreeBSD 9.1-STABLE #0 r250121: Wed
> May 1 23:38:36 EEST 2013
> r...@ion.uabsd.org:/usr/obj/usr/src/sys/GENERIC i386)
>
> mount command:
> mount -t nfs -o ro,nfsv3,tcp 192.168.56.1:/home/bsd/src /usr/src
>
> Fix: add option fsid=(1000 or any number) to /etc/exports . I don't
> understand, Why fsid is so important?
Sounds like a question for the Linux NFS mailing list. All I can mention is
that most NFS servers use an fsid to uniquely identify a file system on the
server. It is often a part of the file handle.
Anyhow, thanks for letting us know. If someone reports a similar problem,
we can suggest trying adding fsid= to their Linux server's export line.
Thanks, rick
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: multiple NFS mounts with bg,retrycount=0
Zaphrod Beeblebrox wrote: > [about double background NFS mounts] > > I'm not sure on the fix to this, but I'm pretty sure it's because we > retry > the mount -a stuff twice at startup. If you watch your console, you'll > see > two places where it will "mount NFS filesystems" during boot. > > ... well... a fix to this would be to _not_ do that twice ... but hey > :). There was just a commit to head (r250253) which adds a "-L" option to mount, so that only "late" file systems are mounted, to avoid this. Without this, what I think happens is: A - "mount -a" --> initial mount attempt fails and goes background B - "mount -a -l" --> succeeds in doing the mount, since it isn't mounted yet - background mount_nfs from (A) wakes up and does the mount again Yes, doing the mount twice will work and the second mount covers up the first one. This is relatively harmless, although it will take 2 umounts to get rid of the mount (the first umount just uncovers the first mount). You could try marking the /etc/fstab line(s) for the mounts "late". (since you use "bg", I'm assuming they aren't needed to be done for the startup scripts) That way they would only be mounted for the "mount -a -l" case, I think. rick > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: multiple NFS mounts with bg,retrycount=0
On Mon, 2013-05-06 at 10:48 -0700, Navdeep Parhar wrote: > I updated a FreeBSD 9-STABLE system to r250290 and noticed an NFS oddity > -- fstab entries that specify a retrycnt are mounted multiple times. > > I have this in /etc/fstab: > :/remote/ /local/ nfs rw,bg,retrycnt=0 0 0 > > And this in /etc/rc.conf: > rpcbind_enable="YES" > nfs_client_enable="YES" > nfs_server_enable="YES" > nfsv4_server_enable="YES" > nfsuserd_flags="-domain XX" > rpc_lockd_enable="YES" > rpc_statd_enable="YES" > > If I run mount immediately after the system boots up I don't see > anything mounted on /local/. If I wait a minute or so and recheck I > see two identical mounts on /local/. > > # mount | grep /local > :/remote/ on /local/ (nfs) > :/remote/ on /local/ (nfs) > > It is almost as if the system tried to mount the remote FS, failed, and > then forked multiple (?) processes to retry the operation, and all of > them succeed later. Unfortunately, I can't reboot the system for a > couple of days so I can't go looking for mount_nfs processes right after > a fresh boot. > > Regards, > Navdeep I see the very same here on FreeBSD 10.0-CURRENT boxes (two boxes acting as NFSv4 server). The clients (all FBSD 10, one 9.1-STABLE) have two(!) identical mounts of the very same filesystem. /etc/fstab does contain the mount option "bg", but not "retrycnt=0". This behaviour happens on ALL FBSD 10.0-CURRENT boxes I administer (10.0-CURRENT #0 r250275: Sun May 5 18:40:17 CEST 2013 amd64). Regards, Oliver signature.asc Description: This is a digitally signed message part
Re: multiple NFS mounts with bg,retrycount=0
On Mon, May 06, 2013 at 03:46:51PM -0400, Zaphod Beeblebrox wrote:
> [about double background NFS mounts]
>
> I'm not sure on the fix to this, but I'm pretty sure it's because we retry
> the mount -a stuff twice at startup. If you watch your console, you'll see
> two places where it will "mount NFS filesystems" during boot.
>
> ... well... a fix to this would be to _not_ do that twice ... but hey :).
Preface: I'm not aware of mount(8) actually permitting the mounting of
two NFS filesystems at the same mountpoint (e.g. wouldn't the 2nd one
throw EPERM or some other condition?).
When I ran my co-lo, we used NFS on many client machines (on RELENG_8
and RELENG_9) and we *never* saw multiple mounts (to the same
mountpoint) on reboot. I also don't remember seeing the message in
question twice -- only once.
That said:
Can you please determine if /etc/rc.d/mountcritremote is doing this?
This is the only script which issues such echo statements. The
relevant portion of the script:
35 mountcritremote_start()
36 {
37 # Mount nfs filesystems.
38 #
39 case "`/sbin/mount -d -a -t nfs`" in
40 '')
41 ;;
42 *)
43 echo -n 'Mounting NFS file systems:'
44 mount -a -t nfs
45 echo '.'
46 ;;
47 esac
48
49 # Mount other network filesystems if present in /etc/fstab.
50 case ${extra_netfs_types} in
51 [Nn][Oo])
52 ;;
53 *)
54 netfs_types="${netfs_types} ${extra_netfs_types}"
55 ;;
56 esac
57
58 for i in ${netfs_types}; do
59 fstype=${i%:*}
60 fsdecr=${i#*:}
61
62 [ "${fstype}" = "nfs" ] && continue
63
64 case "`mount -d -a -t ${fstype}`" in
65 *mount_${fstype}*)
66 echo -n "Mounting ${fsdecr} file systems:"
67 mount -a -t ${fstype}
68 echo '.'
69 ;;
70 esac
71 done
And the defaults for $netfs_types and $extra_netfs_types:
netfs_types="nfs:NFS oldnfs:OLDNFS smbfs:SMB portalfs:PORTAL nwfs:NWFS" # Net
filesystems.
extra_netfs_types="NO"# List of network extra filesystem types for delayed
Now look at lines 58 through 62 above (specifically 62). $fstype
should contain "nfs" thus should be skipped over. And "oldnfs" would
cause the echo statement to be "Mounting OLDNFS file systems:".
If you could try to figure out where/what rc script is causing this
for you, that'd be great.
And a final point: disclose of exactly what FreeBSD version you're using
(including build date or SVN rXX number) would be wonderful. The
reason I mention that is because mountcritremote has been adjusted
**after** 9.1-RELEASE (see r242153):
http://svnweb.freebsd.org/base/stable/9/etc/rc.d/mountcritremote
Let us know what you find.
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: multiple NFS mounts with bg,retrycount=0
[about double background NFS mounts] I'm not sure on the fix to this, but I'm pretty sure it's because we retry the mount -a stuff twice at startup. If you watch your console, you'll see two places where it will "mount NFS filesystems" during boot. ... well... a fix to this would be to _not_ do that twice ... but hey :). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Login failures usefulness with OpenSSH 6.1
Jason Hellenthal writes: > I used to get username and IP address in the output but it seems that > the logging format has changed. Instead of one line the log format now > has two lines. One like the ones below and then another coinciding > line that contains IP address and username. It will be much easier to help you if you show us exactly what you expected and what you got instead. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
multiple NFS mounts with bg,retrycount=0
I updated a FreeBSD 9-STABLE system to r250290 and noticed an NFS oddity -- fstab entries that specify a retrycnt are mounted multiple times. I have this in /etc/fstab: :/remote/ /local/ nfs rw,bg,retrycnt=0 0 0 And this in /etc/rc.conf: rpcbind_enable="YES" nfs_client_enable="YES" nfs_server_enable="YES" nfsv4_server_enable="YES" nfsuserd_flags="-domain XX" rpc_lockd_enable="YES" rpc_statd_enable="YES" If I run mount immediately after the system boots up I don't see anything mounted on /local/. If I wait a minute or so and recheck I see two identical mounts on /local/. # mount | grep /local :/remote/ on /local/ (nfs) :/remote/ on /local/ (nfs) It is almost as if the system tried to mount the remote FS, failed, and then forked multiple (?) processes to retry the operation, and all of them succeed later. Unfortunately, I can't reboot the system for a couple of days so I can't go looking for mount_nfs processes right after a fresh boot. Regards, Navdeep ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
