Very Computer

I was going through the Insight documentation and it mentions
LoFS in the context of autofs and NFS, but not elsewhere.

I was wondering if IRIX 6.5.x supports mounting files which
contain a filesystem image, such as ISO9660 or a dd of an
efs filesystem, similar to the loopback filesystem under Linux.
--

The loopback filesystem under IRIX is not the same thing (at all)
as the loopback filesystem under Linux.

IRIX lofs is a shortcut though the filesystem layers so that when
a machine NFS mounts it's own local filesystems, you don't pay
the overhead of the NFS layers. Instead IRIX will go directly to
the underlying filesystem, cutting NFS out of the loop for the
most part.

As you can see, this has nothing at all to do with the Linux
loopback filesystem. Completely different things (at least by
my understanding -- I'm not terribly familiar with Linux
filesystems).

As a side note: Expect some major IRIX lofs performance improvements
when 6.5.10 hits the street.

Hope that helps,
Brent

--

Kernel Engineer           http://reality.sgi.com/bcasavan
Silicon Graphics, Inc.

Thank you for the clarification; I look forward to trying out
NFS over Gb Ethernet with the 6.5.10 release.

So does IRIX have any way of mounting an image file onto the
filesystem?
--

Quote:

> So does IRIX have any way of mounting an image file onto the
> filesystem?

no.

Wolfgang

Just curious... why would you want to NFS mount a local filesystem?

Damian Menscher
--


--==## Physics Dept, 1110 W Green, Urbana IL 61801 Fax:(217)333-9819 ##==--

: Just curious... why would you want to NFS mount a local filesystem?

That's quite common in situations where you have a tightly coupled
bunch of workstations or servers, each holding a fraction of your
data, and want them to appear identical to the users - at least as
far as the file locations are concerned. In this case, you have a
choice between maintaining distinct fstab (or automounter maps, or
whatever autofs uses) for each and every system, or having identical
system configuration files - and using loopback NFS mounts.

When the performance hit of a loopback mount approaches negligible
(as it apparently does with lofs), I know which one I'll use ...

/Serge.P

---
Home page: http://www.cobalt.chem.ucalgary.ca/ps/

:: Just curious... why would you want to NFS mount a local filesystem?
:
:That's quite common in situations where you have a tightly coupled
:bunch of workstations or servers, each holding a fraction of your
:data, and want them to appear identical to the users - at least as
:far as the file locations are concerned. In this case, you have a
:choice between maintaining distinct fstab (or automounter maps, or
:whatever autofs uses) for each and every system, or having identical
:system configuration files - and using loopback NFS mounts.
:
:When the performance hit of a loopback mount approaches negligible
:(as it apparently does with lofs), I know which one I'll use ...

Another reason for loopback NFS mounts is if you're interested in
having chroot()ed portions of your system access data sitting in a
non-chroot()ed portion of your system.  And it's especially fun and
helpful to mount with different options (read-only, nosuid, etc.)
within your chroot() than from the system "in general".  

--

 Royal Oak, Michigan | (has my PGP & Geek Code info) | Phone: +1 248-848-4481

Yes, exactly. Here's an illustration which might help.

Say you have two software development workstations, 'alice' and 'bill',
and a big file server and build server 'charlie'. charlie serves files
by NFS, and has a huge filesystem used for holding source code work areas
for a couple hundred users.

When sitting at alice or bill working on files, you do stuff like:

        alice 40% cd /hosts/charlie/huge_filesystem/user1/src
        alice 41% vi main.c

However, since the source code is so huge, you always do builds on
charlie:

        charlie 5% cd /hosts/charlie/huge_filesystem/user1/src
        charlie 6% make

Now, you notice that on charlie we're using the same automount map
as the workstations used. We could have just done this:

        charlie 5% cd /huge_filesystem/user1/src
        charlie 6% make

However, your users will all hate you because the path to the exact
same files is different depending on which machine they log into. You
can gain their love and admiration by allowing them to always use the
same path to get to their data.

With this you can supply fairly low-power desktops, but provide a
very fast build server. You also gain the benefit of only needing
to back up the big file server filesystems instead of the filesystems
on hundreds of desktop machines.

Now, say charlie is an IRIX machine. Whenever a user accesses
/host/charlie/huge_filesystem from charlie itself, they're accessing an
automounted NFS filesystem.  Everything would work just fine if charlie
sits there babbling NFS to itself over 127.0.0.1, but there's a better way.
That's where 'lofs' comes in.

When charlie tries to NFS mount /hosts/charlie/huge_filesystem, it can
realize "Hey, this is actually *my* filesystem I'm mounting, let's cut out
the middleman." So, at some of the lower layers of filesystem code, instead
of accesses causing NFS reads and writes, those reads and writes go directly
to the underlying filesystem. This results in a pretty slick performance
improvement.

Note however that you don't eliminate all overhead. The operating system
must still check mount-point and NFS export priveleges on
/hosts/charlie/huge_filesystem, because they *might* be different than
the priveleges allowed to /huge_filesystem itself (i.e. charlie might
NFS export huge_filesystem read-only, but accesses through /huge_filesystem
are read-write). However you do cut out tons and tons of protocol overhead.

So, I hope that serves as an example of where NFS mounting your own
filesystems is useful, and what 'lofs' might gain you in such a situation.

Brent Casavant

--

Kernel Engineer           http://reality.sgi.com/bcasavan
Silicon Graphics, Inc.

Hi Brent

Brent Casavant schrieb:

Quote:

> Say you have two software development workstations, 'alice' and 'bill',
> and a big file server and build server 'charlie'. charlie serves files
[snip]
> Now, say charlie is an IRIX machine. Whenever a user accesses
> /host/charlie/huge_filesystem from charlie itself, they're accessing an
> automounted NFS filesystem.  Everything would work just fine if charlie
> sits there babbling NFS to itself over 127.0.0.1, but there's a better way.
> That's where 'lofs' comes in.

I have a similar automount scenario and use mount maps of the type

 host==charlie;type:=link;fs:=/users
 host!=charlie;type:=nfs;rhost:=charlie;rfs:=/users

Isn't linking instead of NFS/lofs-mounting even more direct and with
even less overhead?

Bye

Uli

ulrich.vcf < 1K Download

Well yes, but I was simplifying a bit. Remember that charlie may not
be the only large server that needs administering, and the benefits
of a single auto_master NIS map across the facility is a desirable thing.

Remember too that the example I gave isn't the only good use of lofs.
Consider, as someone else mentioned, a set of say 80 workstations,
each with their own local drives, but not necessarily a central file
server. The only consistent and administratively scalable way to
provide access to all those filesystems is to NFS export the filesystems,
and have an automounter map that lets you get to /hosts/doug, /hosts/erica,
/hosts/frank, /hosts/gretchen, /hosts/hugo, etc. The benefits of lofs
may not be utmost in the administrators mind when setting up this system,
but when logged into 'ivan' you'll be glad that /hosts/ivan is a lot faster
to access than /hosts/julia.

The real power of this scheme is the combination of NFS, lofs, and NIS
automounter maps. I find automount(1) some pretty fascinating reading,
but then again I've been accused of being a nerd more than once in my
life.

So, yes, in the particular instance you named, performance would be a
tiny bit better using a symlink rather than lofs, but in the more general
scheme of things an optimized short-cut through NFS is certainly a
desirable thing.

Hope that helps,
Brent

--

Kernel Engineer           http://reality.sgi.com/bcasavan
Silicon Graphics, Inc.

: Isn't linking instead of NFS/lofs-mounting even more direct and with
: even less overhead?

It is. It may also also a horrible headache for a system administrator:
with automount symlinks, /bin/pwd will return different paths on different
systems. For example, on most of my systems, pwd in my home directory
says:

/tmp_mnt/cobalt18/usr/people/patchkov/

However, on one of them, it says:

/local/people/patchkov/

Now, the first name, although lacking the automount magic, _will_ work
on most of the systems - as long as my home directory is already mounted
at this point (and it will be - thanks to my shell reading the startup
files). However, on _one_ of the systems, it will fail. Somewhat similarly,
the second name will work on one of the systems - and fail on all the
others.

At one point, problems created by user-created batch job script failing
to execute "randomly", depending on the node allocated by the batch
queuing system, and on the submission node, accounted for about 50% of
the help requests I was getting ...

Cheers,

/Serge.P

---
Home page: http://www.cobalt.chem.ucalgary.ca/ps/

Hello Brent,

be patient ... I still didn't get it

Brent Casavant schrieb:

Quote:> Well yes, but I was simplifying a bit. Remember that charlie may not
> be the only large server that needs administering, and the benefits
> of a single auto_master NIS map across the facility is a desirable thing.

Say charlie holds the homes of frank and karl and ivan holds the home of
sabine. Then my automounter map would look like:

frank  host==charlie;type:=link;fs:=/users \
       host!=charlie;type:=nfs;rhost:=charlie;rfs:=/users
karl   host==charlie;type:=link;fs:=/users \
       host!=charlie;type:=nfs;rhost:=charlie;rfs:=/users
sabine host==ivan;type:=link;fs:=/users \
       host!=ivan;type:=nfs;rhost:=charlie;rfs:=/users

This would be a single map across the facility.

Quote:

> Consider, as someone else mentioned, a set of say 80 workstations,
> each with their own local drives, but not necessarily a central file
> server. The only consistent and administratively scalable way to
> provide access to all those filesystems is to NFS export the filesystems,
> and have an automounter map that lets you get to /hosts/doug, /hosts/erica,
> /hosts/frank, /hosts/gretchen, /hosts/hugo, etc.

That's in my opinion the scenario (with some more hosts) I gave above,
isnt't it ??

Quote:

> The real power of this scheme is the combination of NFS, lofs, and NIS
> automounter maps.

Well, replace lofs with link and it's what I'm doing.

Quote:> So, yes, in the particular instance you named, performance would be a
> tiny bit better using a symlink rather than lofs, but in the more general
> scheme of things an optimized short-cut through NFS is certainly a
> desirable thing.

Perhaps there's a more striking example (or I still can't see how
striking yours is).
Please get me right, I'm always looking for improvements to the way I
managed my $HOMES.

--
Dr.-Ing. Ulrich Oldendorf
TU Darmstadt / Mechatronik und Maschinenakustik

Ah! Now I understand.

You're using amd, probably on Linux or some other such thing. amd is not
functionally identical to automount on IRIX. automount does not have the
ability to do the "host==charlie" or "host!=charlie" as listed above.
automount works only with NFS, whereas amd works with any filesystem.

I was explaining everything in terms of 'autmount'. With 'amd' you may
be able to do things in a slightly different way, which appears to work
well for you. And my advice, as always, is "If it ain't broke, don't
fix it."

Take care,
Brent Casavant

--

Kernel Engineer           http://reality.sgi.com/bcasavan
Silicon Graphics, Inc.