| 1 |
On Wed, 2006-10-11 at 12:23 -0400, Daniel Barkalow wrote: |
| 2 |
> On Tue, 10 Oct 2006, Anthony E. Caudel wrote: |
| 3 |
> |
| 4 |
> > I have been using Gentoo for more than 2 years now and have always |
| 5 |
> > wondered (but never asked - That's the "dumb" part) how Gentoo manages |
| 6 |
> > to update a package that happens to be running at the time. |
| 7 |
> > |
| 8 |
> > Given that the old version (the one running) is deleted, how does it |
| 9 |
> > manage to keep standing if you just cut its legs off? |
| 10 |
> |
| 11 |
> Userspace technically never "deletes" anything in the UNIX model; it |
| 12 |
> either "truncates" it (not what's going on here) or it "unlinks" it. |
| 13 |
> "Unlink" causes the file not to have the filename any more, and the kernel |
| 14 |
> gets rid of files which aren't in use and have no name (of course, nobody |
| 15 |
> can tell when or if this happens, aside from the disk not filling up, |
| 16 |
> because there would be no way to look at the file anyway). |
| 17 |
> |
| 18 |
> If you look at /proc/<PID>/maps for a program you've upgraded, you'll |
| 19 |
> probably find funny notations in there, indicating that the file it's |
| 20 |
> using is not the file that currently has that filename. |
| 21 |
> |
| 22 |
> ("truncate" and otherwise openning the file for writing actually affect |
| 23 |
> the file, not the filename, and would therefore cause programs to crash if |
| 24 |
> you overwrote them.) |
| 25 |
> |
| 26 |
> Technical terms: the file itself is called an "inode", and the name is a |
| 27 |
> "dentry" (actually, the last part of the path, which is all that goes away |
| 28 |
> in a single operation, is the dentry). A dentry stores the inode number of |
| 29 |
> the inode at that path, and "unlink" removes the dentry. What's actually |
| 30 |
> happening in an upgrade is "rename", which, as a single operation, unlinks |
| 31 |
> any dentry with the destination path, links the source inode to the |
| 32 |
> destination dentry, and unlinks the source dentry. This means that no |
| 33 |
> program can see the path empty or with half of a file or see the file with |
| 34 |
> two names. |
| 35 |
> |
| 36 |
> -Daniel |
| 37 |
> *This .sig left intentionally blank* |
| 38 |
|
| 39 |
Wow, files can exist without file names. I think I found a topic for |
| 40 |
discussion in philosophy class... |
| 41 |
|
| 42 |
-- |
| 43 |
gentoo-user@g.o mailing list |
Archives