| 1 |
On Mon, Jul 25, 2011 at 11:40:55AM +0100, Mick wrote: |
| 2 |
> On Monday 25 Jul 2011 11:24:33 YoYo Siska wrote: |
| 3 |
> > On Mon, Jul 25, 2011 at 11:02:34AM +0100, Mick wrote: |
| 4 |
> > > After some deliberation I've started emerging libreoffice. It gave the |
| 5 |
> > > usual office suite warnings at the beginning that there isn't enough |
| 6 |
> > > space in /var (I have 5.8G and it was asking for more than 7G+). |
| 7 |
> > > |
| 8 |
> > > Half way through the emerge I noticed that I have only 74M left and is |
| 9 |
> > > going down fast! O_O |
| 10 |
> > > |
| 11 |
> > > OpenOffice was able to emerge in the past using this partition size |
| 12 |
> > > without a problem. I've flushed logs and what not to free some space, |
| 13 |
> > > but I'm thinking of extending the partition somehow. I don't run LVM on |
| 14 |
> > > this machine so that's not a solution for this circumstance. |
| 15 |
> > > |
| 16 |
> > > Is there anything I can do with mount --rbind and could I do this in the |
| 17 |
> > > middle of an emerge? I have another partition with loads of space in it, |
| 18 |
> > > but it has a different fs on it (reiser4 instead of /var's ext4). |
| 19 |
> > |
| 20 |
> > You can mount --bind a dir from a large partition to /var/tmp/portage |
| 21 |
> > before an emerge, but you can't do that during a running emerge. However |
| 22 |
> > with a reasonable buildsystem, you could in theory stop the emerge, copy |
| 23 |
> > over the files in /var/tmp/portage to new location (preserving |
| 24 |
> > timestamps) and then try resuming the emerge with FEATURES="keepwork |
| 25 |
> > noclean", though i don't know if that works well with openoffice... |
| 26 |
> > |
| 27 |
> > Also you don't have to mount anything to /var/tmp/portage, you can just |
| 28 |
> > change the dir by setting PORTAGE_TMPDIR to a directory on a partition |
| 29 |
> > with enough space (I normally have my DISTDIR, PKGDIR and PORTAGE_TMP set |
| 30 |
> > on a different partition...) |
| 31 |
> |
| 32 |
> Oh yes! Of course, PORTAGE_TMPDIR .... what was I thinking?!! |
| 33 |
> |
| 34 |
> Thank you. |
| 35 |
> |
| 36 |
> I never understood properly how the mount --bind/rbind works. I understand |
| 37 |
> that the original partition content becomes visible on a second partition, but |
| 38 |
> I'm not at all sure what happens when the space on the first partition runs |
| 39 |
> out? |
| 40 |
|
| 41 |
Not "on a second partition" but under another "mount point" i.e. another |
| 42 |
path... When you try to access a file by its filename, the kernel takes |
| 43 |
the absolute file name, compares it to all the moutend "mount points", |
| 44 |
takes the best match and tries to find (create) the file in that |
| 45 |
filesystem/partition... |
| 46 |
|
| 47 |
Lets say you do something like: |
| 48 |
|
| 49 |
mount /dev/sda1 / (well... you don't actually do this... ;) |
| 50 |
mount /dev/sda2 /mnt/sda2 |
| 51 |
mount --bind /mnt/sda2/bigtmp /tmp |
| 52 |
|
| 53 |
Then path "/home/yoyo/something" is accessing file "home/yoyo/something" |
| 54 |
on partition sda1. |
| 55 |
|
| 56 |
The path "/mnt/sda2/somedir/somefile" is accessing file "somedir/somefile" |
| 57 |
on partion sda2. |
| 58 |
|
| 59 |
The path "/tmp/somedir/somefile" is accessing file |
| 60 |
"bigtmp/somdir/somefile" on partition sda2. |
| 61 |
|
| 62 |
|
| 63 |
The files (and free space) under /mnt/sda2 and /tmp are actually on |
| 64 |
partition sda2, everything else is on sda1... |
| 65 |
|
| 66 |
|
| 67 |
So if sda1 runs out of space (by writing to other places than /mnt/sda2 |
| 68 |
and /tmp), it doesn't in any any way affect /mnt/sda2 and /tmp which |
| 69 |
have their free space from sda2. Conversely if you fill up sda2 by |
| 70 |
writing to /tmp, your "system" partition still has free space ;) |
| 71 |
|
| 72 |
|
| 73 |
yoyo |
Archives