Re: nfs bug df: Can I lock up my kernel and overflow this buffer?

2005-05-10 Thread Jonathan Noack
On 05/10/05 00:21, Billy Newsom wrote:
Jonathan Noack wrote:
  On 05/09/05 23:14, Billy Newsom wrote:
   From the fstab(5) man page:
  The fourth field, (fs_mntops), describes the mount options associated
  with the file system.  It is formatted as a comma separated list of
  options.  It contains at least the type of mount (see fs_type below)
  plus any additional options appropriate to the file system type.  See
  the options flag (-o) in the mount(8) page and the file system specific
  page, such as mount_nfs(8), for additional options that may be 
specified.

That is how I read the man page, too, long ago.  But when I tried the -o 
option on the commandline, I was unable to send mount all of the 
mount_nfs commandline switches I needed.  I either misunderstand the 
mount -o option, or it doesn't work for all of the mount_nfs stuff I 
tried to send it.

In other words, the -o option seems to not like any of the many switches 
understood by mount_nfs  hence I seemed to be forced to use 
mount_nfs directly.  And that precludes using it in fstab.
You are not restricted to only the -o option with fstab.  The native 
mount_nfs switches work fine with it.  This is stated in the second half 
of the last sentence I quoted above (note the and).  Thus, the same 
options you use on the command line work with fstab.

  What trouble did you have with fstab?  You can specify as many options
  as you want as long as you separate them with commas (I think putting a
  '=' between an option and its value is also necessary, although I don't
  know for sure).  For you it should look like this (assuming you want
  read/write):
 
  dell:/nfs  /dellbak  nfs  rw,-s,-x=2,-T  0  0
I don't know.  Since mount wasn't able to understand those switches on 
the commandline, I never tried anything in fstab, for the sake of not 
causing any problems with my boot.
The handbook page on nfs has a few simple examples toward the bottom 
(first hit on a Google search for freebsd nfs fstab):
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-nfs.html

To test the line I gave you just add it to /etc/fstab and see if mount 
/dellbak works.  It'll give you an error message if something is wrong. 
 For example, the options specified work perfectly for me and the mount 
command completes successfully.  Adding a -z to it gives an illegal 
option error.

# grep shared /etc/fstab
server:/shared  /mnt  nfs  rw,-s,-x=2,-T  0  0
# mount /mnt
# umount /mnt
add -z
# grep shared /etc/fstab
server:/shared  /mnt  nfs  rw,-s,-x=2,-T,-z  0  0
# mount /mnt
mount_nfs: illegal option -- z
usage: mount_nfs [-23bcdiLlNPsTU] [-a maxreadahead] [-D deadthresh]
 [-g maxgroups] [-I readdirsize] [-o options] [-R retrycnt]
 [-r readsize] [-t timeout] [-w writesize] [-x retrans]
 rhost:path node
Anyone tried that sort of stuff in fstab?  I'm a little skeptical.
I use that sort of stuff and have for a long time.  Here's one of my 
fstab lines:

optimator:/usr/home  /usr/home  nfs  rw,-3,-T,-r=32768,-w=32768  0  0
It's obvious you don't believe me but why are you unwilling to try it 
yourself?

--
Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195


signature.asc
Description: OpenPGP digital signature


Re: nfs bug df: Can I lock up my kernel and overflow this buffer?

2005-05-10 Thread Billy Newsom
Jonathan Noack wrote:
 Anyone tried that sort of stuff in fstab?  I'm a little skeptical.

 I use that sort of stuff and have for a long time.  Here's one of my
 fstab lines:

 optimator:/usr/home  /usr/home  nfs  rw,-3,-T,-r=32768,-w=32768  0  0

 It's obvious you don't believe me but why are you unwilling to try it
 yourself?
Well, because this fails to work on the commandline:
#mount -o -s -x 2 -T dell:/nfs /dellbak
I tried tons of different ways, never could get mount to do that, so I 
gave up on fstabbing options.

Since the above mount command wouldn't even work, I figured I could 
forget about putting those same options (which mount calls illegal) in 
the fstab file.  That's where the man pages only go so far.  Without the 
examples you give, I was pretty sure that it was pointless to get fstab 
options to do what mount wouldn't.

What it boils down to is that mount is fine with these options in fstab, 
but barfs when doing them on the commandline.  That was so 
couter-intuitive, I went around it for the sake of getting things done.

FreeBSD man pages are nice and all, but without a textbook siting by 
with some examples, it can be difficult.  I learned Unix pretty much ad 
hoc, so I find that examples (such as you gave) are worth much more than 
man pages now that I know most of the basics.

Thanks.
But what I did discover is that if I mount the same nfs resource 
multiple times, I get multiple, identical mounts (using fstab options, 
or commandline, either one).  I have to umount each one serially.  How 
is this a feature?  What good does it do me if I mount the same nfs 
drive to the same place n times?  Won't that eventually cause a deadlock 
as n increases beyond a few hundred or thousand? -- especially when the 
NFS server goes down?  Shouldn't the second and subsequent mounts either 
fail or not be attempted due to a sanity check?

#mount /usr
mount: /dev/ad0s1f: Device busy
Exit 1
That seems reasonable for /usr.  But as I stated before, NFS resources 
nevere apparently become busy, and there is no sanity check to prevent 
mulitiple simultaneous mounts of identical file systems on identical 
file trees.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs bug df: Can I lock up my kernel and overflow this buffer?

2005-05-10 Thread Erik Trulsson
On Tue, May 10, 2005 at 05:16:16PM -0500, Billy Newsom wrote:
 Jonathan Noack wrote:
  Anyone tried that sort of stuff in fstab?  I'm a little skeptical.
 
  I use that sort of stuff and have for a long time.  Here's one of my
  fstab lines:
 
  optimator:/usr/home  /usr/home  nfs  rw,-3,-T,-r=32768,-w=32768  0  0
 
  It's obvious you don't believe me but why are you unwilling to try it
  yourself?
 
 Well, because this fails to work on the commandline:
 
 #mount -o -s -x 2 -T dell:/nfs /dellbak
 
 I tried tons of different ways, never could get mount to do that, so I 
 gave up on fstabbing options.


Note that mount(8) (as well as mount_nfs(8)) says about the -o flag
that Options are specified with a -o flag followed by a comma
separated string of options.

If you try writing it as the manpage says, i.e. like

mount -o -s,-x=2,-T dell:/nfs /dellbak

it should work fine.

 
 Since the above mount command wouldn't even work, I figured I could 
 forget about putting those same options (which mount calls illegal) in 
 the fstab file.  That's where the man pages only go so far.  Without the 
 examples you give, I was pretty sure that it was pointless to get fstab 
 options to do what mount wouldn't.
 
 What it boils down to is that mount is fine with these options in fstab, 
 but barfs when doing them on the commandline.  That was so 
 couter-intuitive, I went around it for the sake of getting things done.

It works fine on the commandline, you just got the syntax for the
commandline wrong.

 
 FreeBSD man pages are nice and all, but without a textbook siting by 
 with some examples, it can be difficult.  I learned Unix pretty much ad 
 hoc, so I find that examples (such as you gave) are worth much more than 
 man pages now that I know most of the basics.

Man pages often have some examples, but learning things only from
manpages can indeed be a bit difficult.

 
 Thanks.
 
 But what I did discover is that if I mount the same nfs resource 
 multiple times, I get multiple, identical mounts (using fstab options, 
 or commandline, either one).  I have to umount each one serially.  How 
 is this a feature?

It is a feature in that the system does exactly what you asked it to
do.  This is usually less painful than systems that try to guess what
you actually meant.

  What good does it do me if I mount the same nfs 
 drive to the same place n times? 

None that I can think of, which doesn't mean that there is no use for
it.

 Won't that eventually cause a deadlock 
 as n increases beyond a few hundred or thousand? -- especially when the 
 NFS server goes down?

Probably not a deadlock, but possible a resource starvation - so don't
do that.

  Shouldn't the second and subsequent mounts either 
 fail or not be attempted due to a sanity check?
 
 #mount /usr
 mount: /dev/ad0s1f: Device busy
 Exit 1
 
 That seems reasonable for /usr.  But as I stated before, NFS resources 
 nevere apparently become busy, and there is no sanity check to prevent 
 mulitiple simultaneous mounts of identical file systems on identical 
 file trees.




-- 
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs bug df: Can I lock up my kernel and overflow this buffer?

2005-05-10 Thread Billy Newsom
Erik Trulsson wrote:
 Note that mount(8) (as well as mount_nfs(8)) says about the -o flag
 that Options are specified with a -o flag followed by a comma
 separated string of options.

 If you try writing it as the manpage says, i.e. like

 mount -o -s,-x=2,-T dell:/nfs /dellbak

 it should work fine.
I felt pretty confident I had tried something of this sort, and of 
course now that you say all of that, it works for me.  I probably didn't 
use the hyphens, nor the equals sign, etc.

 It works fine on the commandline, you just got the syntax for the
 commandline wrong.

But what I did discover is that if I mount the same nfs resource
multiple times, I get multiple, identical mounts (using fstab options,
or commandline, either one).  I have to umount each one serially.  How
is this a feature?


 It is a feature in that the system does exactly what you asked it to
 do.  This is usually less painful than systems that try to guess what
 you actually meant.


 What good does it do me if I mount the same nfs
drive to the same place n times?


 None that I can think of, which doesn't mean that there is no use for
 it.


Won't that eventually cause a deadlock
as n increases beyond a few hundred or thousand? -- especially when the
NFS server goes down?


 Probably not a deadlock, but possible a resource starvation - so don't
 do that.
Which leads me to a test.  I am going to try and take a server down this 
 way and see what resources I can max out or overflow by mounting and 
re-mounting the same thing over and over.  I'll write a shell script 
with an infinite loop, and run it on an old server of mine.  Then maybe 
I'll pull its LAN cable (virtually and actually) and see what happens. 
Perhaps I'll cross-post the results to the hackers list if I get some 
interesting results.

BN
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


nfs bug df: Can I lock up my kernel and overflow this buffer?

2005-05-09 Thread Billy Newsom
Here's something pretty stupid about either the code in mount, df, or 
both.  I'm on the verge of a denial of service if this lasts much 
longer.  When I mount an nfs device more than once, I get this 
ridiculous output from df and mount:

#df
Filesystem  1K-blocksUsed   Avail Capacity  Mounted on
/dev/ad0s1a253678  137554   9583059%/
devfs   1   1   0   100%/dev
/dev/ad0s1e253678  18  233366 0%/tmp
/dev/ad0s1f   7782878 3273986 388626246%/usr
/dev/ad0s1d253678  125386  10799854%/var
devfs   1   1   0   100%/var/named/dev
dell:/nfs 8883912 4104516 477939646%/dellbak
dell:/nfs 8883912 4104516 477939646%/dellbak
dell:/nfs 8883912 4104516 477939646%/dellbak
dell:/nfs 8883912 4104516 477939646%/dellbak
dell:/nfs 8883912 4104516 477939646%/dellbak
dell:/nfs 8883912 4104516 477939646%/dellbak
#mount
/dev/ad0s1a on / (ufs, NFS exported, local)
devfs on /dev (devfs, local)
/dev/ad0s1e on /tmp (ufs, local, soft-updates)
/dev/ad0s1f on /usr (ufs, NFS exported, local, soft-updates)
/dev/ad0s1d on /var (ufs, NFS exported, local)
devfs on /var/named/dev (devfs, local)
dell:/nfs on /dellbak (nfs)
dell:/nfs on /dellbak (nfs)
dell:/nfs on /dellbak (nfs)
dell:/nfs on /dellbak (nfs)
dell:/nfs on /dellbak (nfs)
dell:/nfs on /dellbak (nfs)
Ha, ha!  How many times will this last line repeat itself?  I'm curious 
to see if I can get it to give me a screenful of data.  Will this 
eventually crash the kernel or fill some buffer up?  All I'm doing is 
mounting the same nfs drive over and over.  Normally, mounting a device 
twice will just give a device busy or something.  Is there some sanity 
check missing that will prevent mount_nfs from actually mounting the 
same resource at the same mount point over and over?

Details:
* FreeBSD 5.3.  Updated and compiled in mid-February.  I froze it there 
and may soon upgrade to 5.4, but I don't count on this fixing this issue.

* I needed to make sure I had an nfs drive mounted properly, even after 
a reboot, but didn't want to (couldn't?) put it in fstab.  So cron has 
this particular line(s).

44 10 * * * /sbin/mount_nfs -s -x 2 -T dell:/nfs /dellbak
* I am connecting to a local net NFS server running Windows 2000 and 
Services for UNIX 3.5.  Due to some major problems with rebooting and 
NFS, I determined that I needed some of the special commands (-s -x 2) 
to enable the server to reboot.

* I put the mount_nfs command in cron and in an rc.d startup script 
because I didn't see a way to put all of the options in fstab, nor did I 
particularly enjoy booting the FreeBSD server without connecting to the 
NFS drive I would fill up my root directory pretty fast.

* Look at the fsid for /dellbak below, using verbose output.  Pretty odd.
# mount -v
/dev/ad0s1a on / (ufs, NFS exported, local, writes: sync 165 async 
29170, reads: sync 2308 async 45, fsid f044aa41725bf386)
devfs on /dev (devfs, local, fsid 01ff00040400)
/dev/ad0s1e on /tmp (ufs, local, soft-updates, writes: sync 9 async 
4002, reads: sync 125 async 0, fsid f144aa411e8f31da)
/dev/ad0s1f on /usr (ufs, NFS exported, local, soft-updates, writes: 
sync 420 async 129755, reads: sync 170752 async 1401, fsid f144aa4134661c3c)
/dev/ad0s1d on /var (ufs, NFS exported, local, writes: sync 32187 async 
49433, reads: sync 4043 async 102, fsid f244aa416aeef171)
devfs on /var/named/dev (devfs, local, fsid 02ff00040400)
dell:/nfs on /dellbak (nfs, fsid 03ff00020200)
dell:/nfs on /dellbak (nfs, fsid 04ff00020200)
dell:/nfs on /dellbak (nfs, fsid 05ff00020200)
dell:/nfs on /dellbak (nfs, fsid 06ff00020200)
dell:/nfs on /dellbak (nfs, fsid 07ff00020200)
dell:/nfs on /dellbak (nfs, fsid 08ff00020200)

Any help?
Thanks.
BN
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs bug df: Can I lock up my kernel and overflow this buffer?

2005-05-09 Thread Kris Kennaway
On Mon, May 09, 2005 at 11:14:51PM -0500, Billy Newsom wrote:
 Here's something pretty stupid about either the code in mount, df, or 
 both.  I'm on the verge of a denial of service if this lasts much 
 longer.

Why do you think so?

 When I mount an nfs device more than once, I get this 
 ridiculous output from df and mount:
 
 #df
 Filesystem  1K-blocksUsed   Avail Capacity  Mounted on
 /dev/ad0s1a253678  137554   9583059%/
 devfs   1   1   0   100%/dev
 /dev/ad0s1e253678  18  233366 0%/tmp
 /dev/ad0s1f   7782878 3273986 388626246%/usr
 /dev/ad0s1d253678  125386  10799854%/var
 devfs   1   1   0   100%/var/named/dev
 dell:/nfs 8883912 4104516 477939646%/dellbak
 dell:/nfs 8883912 4104516 477939646%/dellbak
 dell:/nfs 8883912 4104516 477939646%/dellbak
 dell:/nfs 8883912 4104516 477939646%/dellbak
 dell:/nfs 8883912 4104516 477939646%/dellbak
 dell:/nfs 8883912 4104516 477939646%/dellbak

Why's it ridiculous?  You mounted it more than once, so it appears
more than once in the list of mounted filesystems.

 * Look at the fsid for /dellbak below, using verbose output.  Pretty odd.

Why is it odd?  The fsid is by definition different for different
mounts.

Kris

pgpoQVP1xyMlu.pgp
Description: PGP signature


Re: nfs bug df: Can I lock up my kernel and overflow this buffer?

2005-05-09 Thread Jonathan Noack
On 05/09/05 23:14, Billy Newsom wrote:
snip
Details:
* FreeBSD 5.3.  Updated and compiled in mid-February.  I froze it there 
and may soon upgrade to 5.4, but I don't count on this fixing this issue.

* I needed to make sure I had an nfs drive mounted properly, even after 
a reboot, but didn't want to (couldn't?) put it in fstab.  So cron has 
this particular line(s).

44 10 * * * /sbin/mount_nfs -s -x 2 -T dell:/nfs /dellbak
From the fstab(5) man page:
The fourth field, (fs_mntops), describes the mount options associated 
with the file system.  It is formatted as a comma separated list of 
options.  It contains at least the type of mount (see fs_type below) 
plus any additional options appropriate to the file system type.  See 
the options flag (-o) in the mount(8) page and the file system specific 
page, such as mount_nfs(8), for additional options that may be specified.

What trouble did you have with fstab?  You can specify as many options 
as you want as long as you separate them with commas (I think putting a 
'=' between an option and its value is also necessary, although I don't 
know for sure).  For you it should look like this (assuming you want 
read/write):

dell:/nfs  /dellbak  nfs  rw,-s,-x=2,-T  0  0
--
Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195


signature.asc
Description: OpenPGP digital signature


Re: nfs bug df: Can I lock up my kernel and overflow this buffer?

2005-05-09 Thread Billy Newsom
Jonathan Noack wrote:
 On 05/09/05 23:14, Billy Newsom wrote:

  From the fstab(5) man page:
 The fourth field, (fs_mntops), describes the mount options associated
 with the file system.  It is formatted as a comma separated list of
 options.  It contains at least the type of mount (see fs_type below)
 plus any additional options appropriate to the file system type.  See
 the options flag (-o) in the mount(8) page and the file system specific
 page, such as mount_nfs(8), for additional options that may be 
specified.

That is how I read the man page, too, long ago.  But when I tried the -o 
option on the commandline, I was unable to send mount all of the 
mount_nfs commandline switches I needed.  I either misunderstand the 
mount -o option, or it doesn't work for all of the mount_nfs stuff I 
tried to send it.

In other words, the -o option seems to not like any of the many switches 
understood by mount_nfs  hence I seemed to be forced to use 
mount_nfs directly.  And that precludes using it in fstab.

 What trouble did you have with fstab?  You can specify as many options
 as you want as long as you separate them with commas (I think putting a
 '=' between an option and its value is also necessary, although I don't
 know for sure).  For you it should look like this (assuming you want
 read/write):

 dell:/nfs  /dellbak  nfs  rw,-s,-x=2,-T  0  0

I don't know.  Since mount wasn't able to understand those switches on 
the commandline, I never tried anything in fstab, for the sake of not 
causing any problems with my boot.

Anyone tried that sort of stuff in fstab?  I'm a little skeptical.
Thanks.
BN
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]