Re: Re (2): HOW does 'loop' work ?

From	Tauno Voipio <tauno.voipio@notused.fi.invalid>
Newsgroups	alt.os.linux.slackware, comp.os.linux.misc
Subject	Re: Re (2): HOW does 'loop' work ?
Date	2011-04-25 22:36 +0300
Organization	A noiseless patient Spider
Message-ID	<ip4ifk$na8$1@dont-email.me> (permalink)
References	<ip1eff$9ar$1@dont-email.me> <ip4fbr$v0c$1@dont-email.me>

Cross-posted to 2 groups.

Show all headers | View raw

no.top.post@gmail.com wrote:
> In article <ip1eff$9ar$1@dont-email.me>, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote: 
> 
>> On 24.4.11 2:28 , no.top.post@gmail.com wrote:
>>> References:<iohio5$rs4$1@dont-email.me>
>>>
>>> In article<iohio5$rs4$1@dont-email.me>, Tauno Voipio<tauno.voipio@notused.fi.invalid>  wrote:
> -- snip --
>>> For making a bootable-USBstik, why do they need to go via 
>>> loop, instead of just directly writing [cp &  edit] to the USBstik.
>> The main reason seems to limit the count of writes on the
>> Flash chips in the USB stick. Building the file system
>> needs plenty of writes and re-writes on the base file
>> device. It loads the stick much less when a ready-made
>> image is just transferred to the stick.
>>
> OK, this suble reason, is what adds complication in understanding
> the 'model', and <loopFS> existed BEFORE Flash chips.
> What was the motivation/use originally?

The motivation for the loop driver is flexibility: It allows
a file system to be built and handled on any file, not only
on block devices.

A file and a block device are conceptually similar random-access
memories. This is related to the fact that you can read and write
directly disks and/or partitions like writing or reading
a random-access file, provided you have sufficient privileges.
This is actually how an initial file system is made on a disk,
loop device or disk partition.

>>> A confusing fact, confirmed experimentally,
>>> which may be relevant,
>>> is that a 'new' `mount<device>  /mnt`,
>>> masks only PART of the previous '/mnt-tree'.
>> I do not quite grab you - the mount masks the
>> whole file tree under the mount point, and only it.
>> Just read any textbook on Unix file systems.
> 
> Yes I discovered that refinement 'during this tutorial'.
> It allows suble side effects.
> Previously I thought `mount /dev/hd1 /mnt/tmp; 
> mount /dev/hd2 /mnt/tmp`  would report an error.

The mount mechanism leaves visible the file system mounted last.

> Also the related `bind` confuses me.
> If `bind` allows 2 different 'targets to be mounted at the
> same mount-point, which one is accessed by
> <read mount-point> ?

See above.

For more information, get a book of Linux VFS (Virtual File System).

-- 

Tauno Voipio

Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: HOW does 'loop' work ? no.top.post@gmail.com - 2011-04-24 11:28 +0000
  Re: HOW does 'loop' work ? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2011-04-24 18:09 +0300
    Re (2): HOW does 'loop' work ? no.top.post@gmail.com - 2011-04-25 18:43 +0000
      Re: Re (2): HOW does 'loop' work ? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2011-04-25 22:36 +0300
      Re: Re (2): HOW does 'loop' work ? Kevin Snodgrass <kdsnodgrass@yahoo.com> - 2011-04-26 00:02 +0000
        Re (3): HOW does 'loop' work ? no.top.post@gmail.com - 2011-04-27 13:16 +0000
      Re: Re (2): HOW does 'loop' work ? Robert Nichols <SEE_SIGNATURE@localhost.localdomain.invalid> - 2011-04-25 22:16 -0500

csiph-web