Re: [9fans] replica's _* files

Re: [9fans] replica's _* files

[geoff]

The reason to keep _ binaries around is that when you have multiple
cpu servers and terminals, until you've rebooted (or shutdown) all
your cpu servers and all your terminals, it's not safe, in general, to
remove old binaries.  A particularly good time to remove them is after
restarting your file server.

Re: [9fans] replica's _* files

[Ronald G Minnich]

geoff@collyer.net wrote:
> The reason to keep _ binaries around is that when you have multiple
> cpu servers and terminals, until you've rebooted (or shutdown) all
> your cpu servers and all your terminals, it's not safe, in general, to
> remove old binaries.  A particularly good time to remove them is after
> restarting your file server.

see: NFS sillyrename(). Another way the problem was solved :-)

ron

Re: [9fans] replica's _* files

[Gorka guardiola]

If I got it right, you didnt. This is for files which are already being executed
and loaded in demand so that, for example the rio *which is alredy running*
doesnt get broken if all the binary is not loaded yet. The file is already in
use, so the name doesnt get resolved again. As long as you dont delete
it will continue to be used even if you rename it.

On 4/18/06, Sascha Retzki <sretzki@gmx.de> wrote:
> On Tue, Apr 18, 2006 at 07:44:47PM +1000, Bruce Ellis wrote:
> > unfortunately this method does'nt solve the problem.
> > [...]
> > i'd rather them be rename in _i++.
> >
>
> Actually I reboot after an update automatically, exactly because of this
> problem; I don't see a reason for a renaming in the first place.
> Informing the user that he shall reboot should be enough.
>
>
> And, did I get it right, you rename files which may be executed, so how
> do these actually know about that? Something needs to be changed so
> that pages are loaded from _rio, else that prefixing-part is rendered
> useless.
>
>
> So it is probably just me who sees "bloat" here... my two cents
>
>


--
- curiosity sKilled the cat

Re: [9fans] replica's _* files

[Sascha Retzki]

On Tue, Apr 18, 2006 at 07:44:47PM +1000, Bruce Ellis wrote:
> unfortunately this method does'nt solve the problem.
> [...]
> i'd rather them be rename in _i++.
>

Actually I reboot after an update automatically, exactly because of this
problem; I don't see a reason for a renaming in the first place.
Informing the user that he shall reboot should be enough.


And, did I get it right, you rename files which may be executed, so how
do these actually know about that? Something needs to be changed so
that pages are loaded from _rio, else that prefixing-part is rendered
useless.


So it is probably just me who sees "bloat" here... my two cents

Re: [9fans] replica's _* files

[Bruce Ellis]

unfortunately this method does'nt solve the problem.

you have to reboot after a replica/pull ... unless
you don't indeed to do it again.

simple exmple ... your rio, which has been running
for weeks/months becomes _rio ... and the next
update overwrites your _rio.

correct me if i'm wrong.

i'd rather them be rename in _i++.

brucee

On 4/18/06, Russ Cox <rsc@swtch.com> wrote:
> When a new binary (e.g., /386/bin/rio) gets pulled,
> the old one, which you might still be running,
> is renamed to the _ version so that it keeps working.
> If you remove _rio while someone is still executing
> it and then they try to demand load a page from the binary,
> the running rio will die.
>
> After rebooting the machine so that you're running the
> new binaries, then it's safe to remove _*.
>
> There is no fossil console command to zero unused fossil blocks.
> The source is in /sys/src/cmd/fossil if you'd like to add one.
>
> Russ
>
>

Re: [9fans] replica's _* files

[Russ Cox]

When a new binary (e.g., /386/bin/rio) gets pulled,
the old one, which you might still be running,
is renamed to the _ version so that it keeps working.
If you remove _rio while someone is still executing
it and then they try to demand load a page from the binary,
the running rio will die.

After rebooting the machine so that you're running the
new binaries, then it's safe to remove _*.

There is no fossil console command to zero unused fossil blocks.
The source is in /sys/src/cmd/fossil if you'd like to add one.

Russ

[9fans] replica's _* files

[Lluís Batlle i Rossell]

After doing a replica "pull", I've seen many new _* files in my plan9 
filesystem. I can easily write a script for deleting them - I imagine 
they're copies of the old files. By now as I'm a new user who 
understands a little about the system, I can simply remove them all. But 
that points me to another question: if I'm using a fossil-only 
installation, can I "zero" the contents of the disk where those files 
were stored? I think maybe there's a fossil command for zeroing the free 
blocks... That would help compressing the qemu images of plan9 disks.

Thanks in advance,
Lluís