Space saver: mount --bind mention in the book?

Bill Maltby LFS Related lfsbill at wlmcs.com
Mon Sep 23 15:05:01 PDT 2002


On Mon, 23 Sep 2002, Bill Maltby LFS Related wrote:
> On Mon, 23 Sep 2002, Timothy Bauscher wrote:
> > On Sun, Sep 22, 2002 at 10:14:10PM -0500, Bruce Dubbs wrote:
> > <snip mount --bind>
> > 
> > > This suggestion sounds perfect for a hint to me.
> > 
> > Agreed. Bill, would you be so kind? A reference to the hint
> > would be added to the book.
> 
> I was afraid of this. Not the work, but the "out-of-hand" thinking that it
> is most appropriate as a hint.[...]

> Sound OK? I'll wait an hour or two and if I "hear" no "Nay" votes, I'll
> offer a few arguments for direct inclusion.
> 
> Of course, we could shorten the whole process if y'all would just Think
> Right (TM), like I do.   ;)

OK. Recap is there are some benefits to mount --bind (if available on the
host distro), and regardless, to (possibly) making a separate partition
for holding sources (and some other things?). I suggested some mentions in
the book and others suggested a hint is more appropriate. I said "Wait!",
let's take a critical look and see. This is my start of that "look-see".

1) Background. Steady progress in the bloat factor has HD space needs
   slowly and inevitably increasing. Also, there seems to be (basd on the
   noise level) a lot more "less experienced" users jumping on the LFS
   bandwagon. Larger HDs are becoming more common in the community. CD-R,
   CD-RW and equivalent capability seems to be also increasing.

   The "bloat factor" is especially aggravated if consideration is given
   to the BLFS activities.

   Many new, and previous users, are using later distros - either an LFS
   installation or later Mandrake, SuSe, RH and so forth.

   I have not observed any increase in the *number* of HDs/installation
   (well, how could I?) and I feel that many are still single-HD setups.

   With LFS 3.3 cvs > 20020521, a static directory and associated proc-
   edural changes were made, that results in 94,920 blocks being used
   (cvs 20020922) that is *potentially* reusable for multiple installs.

2) Assumptions.
   a) a large number of users have configurations with mount with --bind
      available; the number will continue to grow
   b) an ever-increasing number of users have more and larger HDs because
      of the continued downward trend in cost
   c) the LFS community will continue to grow and will do so at an accele-
      rated pace (because of issues discussed elsewhere)
   d) the experience-level of new users can not be expected to improve,
      but only deteriorate, based on recent and on-going trends
   e) the risk and frequency of loss of expensive-to-download and recreate
      software components will continue increase due to both the changes
      in experience-level and increased complexity (think BLFS)
   f) as evidenced by the (apparent) difficulty of getting folks to read
      the already existing FAQs and hints (not to mention the extensive
      system-available documentation), addition of another hint would not
      be as productive as one could hope.

Assertions.
   a) the instructions needed to take advantage of these facilities, even
      allowing for the variety of configuration issues, can be structured
      and integrated into the book in such a way that: simplicity of use
      is maintained; risk of new error due to these new instructions is
      minimized; a large number of users can/will benefit
   b) if b) appears to be false at some point prior to integration into
      the book (through trials?), the planned document can be easily
      converted to a hint and whatever benefits that provides are still
      available.

Basic Strategy. At points in the book where a single partition is now
advocated, changes would be made that let the users select a configura-
tion strategy amenable to their hardware configuration and/or experience
level (over-confidence?). For some, this would be one or more additional
partitions (all smaller than the current 1GB, ignoring BLFS, - total re-
quirements should be the same or less) into which they could place their
sources (freeing host distro space if desired) and/or static partition
(combined with sources or separate?). For others, they could take advant-
age of the mount --bind to leave sources in place in the host distro par-
tition (if desired) and/or even create their /static partition in the host
partition. Still others can take advantage of CD* capability to accomplish
several things.

When these decisions are made by the user, *then* they should/could be
directed to an appendix that details *setup* for the choice made. In this
way, pollution of the main thrust of existing setup is reduced to a few
lines about how to make an appropriate decision (factors to consider and
so on) and reference to an appropriate appendix. Because the needed
information is within the same document, url reference is still available
and for text users it is there, but out of the way.

These changes could be supported by adding appropriate entries in the
host's /etc/fstab (detailed in the appendices, not the mainline) to reduce
manual mounting and risk of error. Also, an alias or tiny mount script
would be generated that assured correct mounting/unmounting at the appro-
priate places (could eliminate changes to /etc/fstab in the host) and
would mount read-only and/or bind as/at appropriate places.

Benefits Expected.
   a) risk and frequency of accidental destruction of sources (and certain
      other things), which I believe is becoming more likely, *may* be al-
      most completely eliminated; more (new) users will be more likely to
      apply these sound error-reducing techniques because of their appear-
      ance  directly in the book; experienced users will also benefit because
      we *all* make mistakes sooner or later

   b) faster initial installs (minimal) due to read-only mounting (as
      appropriate) eliminating access time updates for components in the
      read-only partitions

   c) faster ininital and secondary installs (substantial) if sources
      and/or static partitions/directories are on a drives or IDE ports
      different than those hosting the install process

   d) faster secondary installs (substantial) if the static directory is
      kept across installs (where appropriate); this could save 2 hours
      and 21 minutes, for example, on my IBM6x86-II PR-300 unit (256MB
      PC-133 SDRAM,10K rpm 20GB IBM HD target and a junk Quantum as the
      host - each on separate IDE ports). My total run time is at 8.8
      hours on that unit

   e) faster (substantial) installs if the user is able to take advantage
      of a CD on another IDE port, even if only one HD is available

   f) reduced HD space requirements (variable depending on details of
      implementation and strategy user selects) due to "single copy" only
      of sources even if no CD is available (or not used)

   g) reduced help requests on the lists (? this one is iffy in that I
      have no strong gut hunch as to past, present or future error rates
      and help requests due to items that these proposals address).

Well, there are some other benefits but they are *totally* speculative, at
best. So I forego them here.

It seems to me that the primary areas of discussion will center around
philosophy (do we want this kind of stuff "polluting" the mainline of the
book), feasibility (can it be done as cleanly as has been asserted),
utility (will it really be all that useful and used that much, especially
by noobs), maintainability and benefits (other than speed?).

In other words, in total ignorance, having no empirical data, we will
decide the fate of the world (just like 90% of the projects I've had to
work on) based on assumptions, speculation and personal bias.

Finally, as I have been using these (and other techniques) for some time,
I am certainly biased *for* inclusion in the book. So my intent is to
basically *monitor* any activity resulting from this while the powers that
be do their thing. If I am requested, I will chip in.

I do hope that some will take each side so that it receives the best of
critical argument from knowledgeable folks on both sides.

Whichever way it goes - I will be happy to contribute to implementation 
of the final decision. And let's remember folks - this is technical, not
*any* reason for anyone to say *anything* that denigrates another's view.


Bill Maltby
billm at wlmcs.com




-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list