Maybe it would would be an idea if Bernd could set the server to do a search and destroy on *_S5R2. I can't be the only person in the world with a bunch of these left over. Can I?
Maybe it would would be an idea if Bernd could set the server to do a search and destroy on *_S5R2. I can't be the only person in the world with a bunch of these left over. Can I?
Yes, you can't do any harm by deleting them (files ending in S5R2 only) now. I doubt it's possible to force this clean-up on clients from the server side with reasonable overhead, because the fact that the files are still lingering there are due to the fact that because of a bug the server lost track os some filee on the clients.
... because of a bug the server lost track os some filee on the clients.
When this old data was finished with, the server was supposed to tell the client to delete both the h1_* files and the l1_* files. The bug that existed for a while was that the delete instruction sent from the server only specified the h1_* files. Consequently, the l1_* files were left behind for a time until the bug was rectified. It occurred at a time when relatively low frequency data was being crunched as you can see from the filenames you quoted.
The small problem that still exists is that these data files are actually still specified in your state file (client_state.xml) and if you just delete the files from your project folder, the BOINC client will notice and will use the recorded URLs to attempt to download fresh copies. If the URLs are still valid, you should get new files. If the URLs are no longer valid, you should get complaints.
Therefore, to be totally safe you should
* Stop BOINC
* Edit the state file to remove the references to the old files (be very careful!)
* Delete the files on disk
* Restart BOINC
I have done this on many dozens of hosts without issue. The block of data that has to be deleted from the state file (one block for each separate data file) looks like the following example which I have extracted from the state file on one of my hosts. Note that this example relates to a current R4 data file and you would be looking for the correct frequency R2 data file in your own case.
If anybody decides to follow these instructions, you do so at your own risk. If you are not comfortable with editing xml files, you should leave well enough alone. Unless you are critically short of disk space, it's no big deal to leave the files alone.
Thanks for that... When you reattach, do you get a new hostID?
I guess you can get your history back together by merging hosts if needed.
The issue with merging hosts is that the merge loses your original number and retains the new one. I'd prefer it did it the other way round as I'm used the looking for 'my' number when checking tasks. Obviously the more projects you crunch for the bigger this issue becomes. (OK, so I'm too dumb to learn new numbers!)
I think I'll toss a coin on whether to edit the XML or just leave the orphaned files well alone.
S5R3 finished
)
See this thread in the cafe.
Cheers,
Gary.
Seeing S5R3 finish has
)
Seeing S5R3 finish has reminded me . . .
l1_0240.00_S5R2
l1_0415.70_S5R2
l1_0240.05_S5R2
l1_0240.10_S5R2
l1_0240.15_S5R2
l1_0240.20_S5R2
l1_0415.65_S5R2
I take it I can delete these now?
Maybe it would would be an idea if Bernd could set the server to do a search and destroy on *_S5R2. I can't be the only person in the world with a bunch of these left over. Can I?
RE: Seeing S5R3 finish has
)
Yes, you can't do any harm by deleting them (files ending in S5R2 only) now. I doubt it's possible to force this clean-up on clients from the server side with reasonable overhead, because the fact that the files are still lingering there are due to the fact that because of a bug the server lost track os some filee on the clients.
CU
Bikeman
RE: ... because of a bug
)
When this old data was finished with, the server was supposed to tell the client to delete both the h1_* files and the l1_* files. The bug that existed for a while was that the delete instruction sent from the server only specified the h1_* files. Consequently, the l1_* files were left behind for a time until the bug was rectified. It occurred at a time when relatively low frequency data was being crunched as you can see from the filenames you quoted.
The small problem that still exists is that these data files are actually still specified in your state file (client_state.xml) and if you just delete the files from your project folder, the BOINC client will notice and will use the recorded URLs to attempt to download fresh copies. If the URLs are still valid, you should get new files. If the URLs are no longer valid, you should get complaints.
Therefore, to be totally safe you should
* Edit the state file to remove the references to the old files (be very careful!)
* Delete the files on disk
* Restart BOINC
I have done this on many dozens of hosts without issue. The block of data that has to be deleted from the state file (one block for each separate data file) looks like the following example which I have extracted from the state file on one of my hosts. Note that this example relates to a current R4 data file and you would be looking for the correct frequency R2 data file in your own case.
l1_0793.30_S5R4
3847680.000000
0.000000
ac965c9785d77c6a2b9e73639929be9b
1
http://einstein.ligo.caltech.edu/download/15a/l1_0793.30_S5R4
http://einstein.phys.uwm.edu/download/15a/l1_0793.30_S5R4
http://einstein.aei.mpg.de/download/15a/l1_0793.30_S5R4
http://einstein.astro.gla.ac.uk/download/15a/l1_0793.30_S5R4
http://einstein.ligo.caltech.edu/download/15a/l1_0793.30_S5R4
http://einstein.phys.uwm.edu/download/15a/l1_0793.30_S5R4
http://einstein.aei.mpg.de/download/15a/l1_0793.30_S5R4
http://einstein.astro.gla.ac.uk/download/15a/l1_0793.30_S5R4
If anybody decides to follow these instructions, you do so at your own risk. If you are not comfortable with editing xml files, you should leave well enough alone. Unless you are critically short of disk space, it's no big deal to leave the files alone.
Cheers,
Gary.
RE: Therefore, to be
)
Another option is to set NNT and when your queue is empty, detach and reattach to the project.
[edit]be sure to report WUs before you detach![/edit]
Seti Classic Final Total: 11446 WU.
RE: Another option is to
)
Thanks for that... When you reattach, do you get a new hostID?
I guess you can get your history back together by merging hosts if needed.
Cheers,
Gary.
RE: ... When you
)
Yes! Been there ... done that! :)
Stan
RE: Thanks for that...
)
The issue with merging hosts is that the merge loses your original number and retains the new one. I'd prefer it did it the other way round as I'm used the looking for 'my' number when checking tasks. Obviously the more projects you crunch for the bigger this issue becomes. (OK, so I'm too dumb to learn new numbers!)
I think I'll toss a coin on whether to edit the XML or just leave the orphaned files well alone.
Thanks all.
Harry C. Beau
)
Harry C. Beau said,
Quite! Especially if you were an early participant with a 2 or 3 digit host id number! :( Then the loss would be greatly felt.
As for me, I've retired enough hosts (an reinstalled BOINC on enough of the rest) that a low host id has long since ceased to be a consideration.
Guess if I wanted to get a low host id number again, I'd have to join a brand new project. But I like the projects I'm in. :)
Stan
RE: Harry C. Beau
)
Yes... My original host number is a 43575! But now...