From: "David B. Ritch" <dritch@hpti.com>
To: Dave Ingram <davei@wolfram.com>
Cc: NFS mailing list <nfs@lists.sourceforge.net>
Subject: Re: recursive NFS export of mounted ISO images
Date: 23 Oct 2002 16:07:58 -0400 [thread overview]
Message-ID: <1035403220.2880.196.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.44.0210231440430.31286-100000@wopr.wolfram.com>
The April Linux Journal had an article on building a virtual CD-ROM
jukebox, and is available here. It sounds a bit like what you are
looking for. It's available here:
http://www.linuxjournal.com/article.php?sid=5639
I don't recall whether it addresses the issues you bring up, but it
might.
dbr
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. :-)
>
> Dave
>
> --
> Dave Ingram
> Tools and Automation Engineer
> Wolfram Research
> 217-398-0700 x776
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
>
> _______________________________________________
> NFS maillist - NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
--
David B. Ritch
High Performance Technologies, Inc.
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2002-10-23 20:13 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
2002-10-23 20:16 ` Dave Ingram
2002-10-23 20:19 ` seth vidal
2002-10-23 20:07 ` David B. Ritch [this message]
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=1035403220.2880.196.camel@localhost \
--to=dritch@hpti.com \
--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