Linux NFS development
 help / color / mirror / Atom feed
From: seth vidal <skvidal@phy.duke.edu>
To: Dave Ingram <davei@wolfram.com>
Cc: nfs@lists.sourceforge.net
Subject: Re: recursive NFS export of mounted ISO images
Date: 23 Oct 2002 16:07:09 -0400	[thread overview]
Message-ID: <1035403629.31676.34.camel@opus> (raw)
In-Reply-To: <Pine.LNX.4.44.0210231440430.31286-100000@wopr.wolfram.com>

[-- Attachment #1: Type: text/plain, Size: 3073 bytes --]

On Wed, 2002-10-23 at 15:51, Dave Ingram wrote:
> 
> 	Hello, we're trying to do something a little odd in NFS that I 
> don't believe is currently possible. However, I have seen in the mail 
> archives that Neil Brown discussed this back in 7-4-2001.
> 
> 	The problem is this:
> 
> 	We have a huge RAID system that houses, among other things, many 
> ISO image files.
> 
> 	The quality assurance people would like to have a "virtual 
> jukebox" that is distributed via NFS to our large array of test machines. 
> This jukebox would contain the mounted ISO images.
> 
> 	However, currently there is no way to have a single parent 
> directory distributed over NFS that will propogate its mounted contents. 
> One must currently define an explicit mount point in /etc/exports (eg: 
> /Jukebox/M-LINUX-L/6.0.0/187885). Additionally, the client must know the 
> explicit mount point to properly mount this shared image.
> 
> 	This is a problem when you want to have several hundred (well, no 
> more than 255 theoretically because of the 8-bit 'minor' device issue with 
> loop devices) ISO images that you'd like to distribute, because you then 
> are responsible for maintaining EVERY explicit mount point for each image, 
> both on the server and each client.
> 
> 	Even more frustrating is the fact that this is going to be an 
> automated dynamic process. That is - as ISO images are automatically built 
> by other systems, we'll want to mount and export their contents 
> automatically. Likewise, we'll need to prune existing ISO images and their 
> respective mounts.
> 
> 	And, there is no way for the client-side to "know" each mount 
> point in an automated fashion. That is - if the ISO builder system 
> generates a new ISO image, mounts it, and distributes it, there is now a 
> unique mount point that the client can't programatically determine.
> 
> 	So - why the heck am I bothering NFS people with this?
> 
> 	Because I am wondering if there is a way to simply have ONE mount 
> point exported and mounted on the client side, and have it recursively 
> inherit each of the mounted image directories within it.
> 
> 	Also - for those who are asking, "Hey dummy - why don't you just 
> mount the images on the NFS server, then copy their contents into /Jukebox 
> in the appropriate directory?!". Well, because our quality assurance 
> people would like to work with the EXACT files that are going to get 
> burned to CD if the build is a success. Copying the files introduces an 
> extra step that makes them nervous. Plus - every ISO image whose contents 
> we must actually COPY means another 600+ megs we have to allocate disk to.
> 
> 	Thoughts, anyone?
> 
> 	If all you can say is, "That's impossible" or "You're a moron" - 
> your reply will find its way into /dev/null. :-)
> 

You might be able to work some dark magic with autofs over the nfs
exported locations.

look into how autofs functions - I think it might just be possible if
you're not afraid of some painful thinking.

-sv


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2002-10-23 20:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-23 19:51 recursive NFS export of mounted ISO images Dave Ingram
2002-10-23 20:07 ` seth vidal [this message]
2002-10-23 20:16   ` Dave Ingram
2002-10-23 20:19     ` seth vidal
2002-10-23 20:07 ` David B. Ritch
2002-10-23 20:17 ` recursive NFS export of mounted ISO images -- Automounter Maps? Bryan J. Smith
2002-10-23 20:29   ` Dave Ingram
2002-10-23 20:44     ` Bryan J. Smith
2002-10-23 20:55       ` Dave Ingram
2002-10-23 21:18         ` Bryan J. Smith

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=1035403629.31676.34.camel@opus \
    --to=skvidal@phy.duke.edu \
    --cc=davei@wolfram.com \
    --cc=nfs@lists.sourceforge.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox