On Mon, Jul 25, 2011 at 11:40:55AM +0100, Mick wrote:
> On Monday 25 Jul 2011 11:24:33 YoYo Siska wrote:
> > On Mon, Jul 25, 2011 at 11:02:34AM +0100, Mick wrote:
> > > After some deliberation I've started emerging libreoffice.  It gave the
> > > usual office suite warnings at the beginning that there isn't enough
> > > space in /var (I have 5.8G and it was asking for more than 7G+).
> > > 
> > > Half way through the emerge I noticed that I have only 74M left and is
> > > going down fast!  O_O
> > > 
> > > OpenOffice was able to emerge in the past using this partition size
> > > without a problem.  I've flushed logs and what not to free some space,
> > > but I'm thinking of extending the partition somehow.  I don't run LVM on
> > > this machine so that's not a solution for this circumstance.
> > > 
> > > Is there anything I can do with mount --rbind and could I do this in the
> > > middle of an emerge?  I have another partition with loads of space in it,
> > > but it has a different fs on it (reiser4 instead of /var's ext4).
> > 
> > You can mount --bind  a dir from a large partition to /var/tmp/portage
> > before an emerge, but you can't do that during a running emerge. However
> > with a reasonable buildsystem, you could in theory stop the emerge, copy
> > over the files in /var/tmp/portage to new location (preserving
> > timestamps) and then try resuming the emerge with FEATURES="keepwork
> > noclean", though i don't know if that works well with openoffice...
> > 
> > Also you don't have to mount anything to /var/tmp/portage, you can just
> > change the dir by setting PORTAGE_TMPDIR to a directory on a partition
> > with enough space (I normally have my DISTDIR, PKGDIR and PORTAGE_TMP set
> > on a different partition...)
> 
> Oh yes!  Of course, PORTAGE_TMPDIR .... what was I thinking?!!
> 
> Thank you.
> 
> I never understood properly how the mount --bind/rbind works.  I understand 
> that the original partition content becomes visible on a second partition, 
> but 
> I'm not at all sure what happens when the space on the first partition runs 
> out?

Not "on a second partition" but under another "mount point" i.e. another
path... When you try to access a file by its filename, the kernel takes
the absolute file name, compares it to all the moutend "mount points",
takes the best match and tries to find (create)  the file in that
 filesystem/partition...

Lets say you do something like:

mount /dev/sda1 /  (well... you don't actually do this... ;)
mount /dev/sda2 /mnt/sda2
mount --bind /mnt/sda2/bigtmp  /tmp 

Then path "/home/yoyo/something" is accessing file "home/yoyo/something"
on partition sda1.

The path "/mnt/sda2/somedir/somefile" is accessing file "somedir/somefile"
on partion sda2.

The path "/tmp/somedir/somefile" is accessing file
"bigtmp/somdir/somefile" on partition sda2.


The files (and free space) under /mnt/sda2  and /tmp are actually on
partition sda2, everything else is on sda1...


So if sda1 runs out of space (by writing to other places than /mnt/sda2
and /tmp), it doesn't in any any way affect /mnt/sda2 and /tmp which
have their free space from sda2. Conversely if you fill up sda2 by
writing to /tmp, your "system" partition still has free space ;)


yoyo

Reply via email to