Mailing List Archive

question on exportfs on ONTAP
HI:

Is there a way to split the entry line in /etc/exportfs om netapp filer? The client is getting panic errors because the exportfs entry is too big!

Thanks
Bob
Re: question on exportfs on ONTAP [ In reply to ]
Bob.Tobaei@netapp.com writes:
>
> HI:

Umph? NetApp are asking us to explain their own systems to them now?
[The message headers don't seem to have been forged.]
[[Ah well, it shows that fubar has unblocked them, anyway!]]

> Is there a way to split the entry line in /etc/exportfs om netapp filer?

Sure (correcting the obvious typo). From the na_exports(5) man page:

| You can use \ for line continuation followed by a carriage
| return at the end of a line. You cannot include comments
| before and after the \.

But still note that

| BUGS
| The filer supports a maximum of 255 host names in each rw
| and root option. There is no limit on the number of host
| names in the list following the access option. The maximum
| size of the /etc/exports file is about 64 KB.

> The client is getting panic errors because the exportfs entry is too big!

Umph? What business is it of the client? What client, anyway?

If you have a client using the MOUNTPROC(3)_DUMP rpc call (via "showmount",
or as part of the implementation of a /net automounter entry, for example).
then the data returned isn't going to be affected by the precise textual
form of the entry in /etc/exports. But maybe you meant something else.

Chris Thompson
Email: cet1@cam.ac.uk
Re: question on exportfs on ONTAP [ In reply to ]
On Thu, Jul 25, 2002 at 10:34:24PM +0100, Chris Thompson wrote:
> > The client is getting panic errors because the exportfs entry is too big!
> Umph? What business is it of the client? What client, anyway?
> If you have a client using the MOUNTPROC(3)_DUMP rpc call (via "showmount",
> or as part of the implementation of a /net automounter entry, for example).
> then the data returned isn't going to be affected by the precise textual
> form of the entry in /etc/exports. But maybe you meant something else.

Indeed. 'Fix a client' would seem good advice.

Or split some data on netapp over multiple qtrees and give clients
only what they need.

Or perhaps consolidate multiply hosts to single network?

Or nis-group, if netapp supports it?

p.