help me understand: "got server request to delete file h1_1413.55_S5R4", etc.
19 Dec 2010 14:41:23 UTC
Topic 195518
(moderation:
so i've noticed lately that i've been getting requests from the server to delete certain files that my client has downloaded. i'm not exactly sure why i get these messages, but i imagine its b/c clients on other computers complete and validate the results of those work units with the server before my machine can get done crunching them itself. i got a pretty simple explanation for this [URL="http://www.boinc-wiki.info/Got_server_request_to_delete_file_%27%28file-name%29%27"]HERE[/URL], which says that my client software will delete the unneeded file. but i'm concerned that they're not actually getting deleted. you see, i'll get a request that looks like this:
got server request to delete file h1_1413.55_S5R4
got server request to delete file l1_1413.55_S5R4
got server request to delete file l1_1413.55_S5R7
got server request to delete file h1_1413.55_S5R7
now while i couldn't find "l1_1413.55_S5R4", "l1_1413.55_S5R7", or "h1_1413.55_S5R7" in my que (b/c 1) everything in my que starts with an "h1" and not an "l1", and 2) b/c everything in my que is a "S5R4" WU, not a "S5R7" WU), i did notice that "h1_1413.55_S5R4" did not disappear from the que after getting its delete request. not only that, but i witnessed BOINC start crunching it like it was any other WU in the que.
why isn't my client software deleting the server-requested files? am i wasting precious CPU cycles on unneeded WU's? or am i just not understanding whats truly going on, and is my client doing everything its supposed to be doing? sorry for the noobish question - i'd just like to better understand what's actually happening, as well as minimize any wasted CPU time if that's in fact happening.
TIA,
Eric
help me understand: "got server request to delete file h1_1413.5
)
Look here.
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
RE: I'm not exactly sure
)
No, you get the "request to delete file" when the server have no more work of this kind to send.
(so you will not need in the future these common to many tasks files).
This is "request to delete". The files will not be deleted immediately.
They will be deleted later when you finish the tasks on-board that need these files.
[pre] [/pre]
thank god there are people
)
thank god there are people here who understand so well what's actually going on beneath the skin of the BOINC client and the E@H application. thank you Gundolf for the link to that detailed explanation, and thanks BilBG for putting it in layman's terms...
...so if i understand this correctly, these are just data files the must be on board in order for tasks of a certain kind to be performed and ultimately for WU's of a certain classification to be crunched...and that my client will dispose of these data files accordingly after whatever tasks/WU's require them in order to be performed/crunched. so basically i just need to let BOINC run its course, as what i'm experiencing is quite normal and are not errors or wasted CPU cycles. again, thank you so much guys.
Eric
That sounds about right Eric.
)
That sounds about right Eric. When you no longer need those files for projects you are currently crunching on, they will be deleted, because there is no more work on the main server that needs them. That frees up room for other files, and in fact when you get new work, you will probably notice a number of new files being downloaded so that it can work on them.
Aaron
If god meant for us not to BOINC he'd have made our #$%^%^ shorter!!
RE: thank god there are
)
Instead of downloading a file for every single unit you crunch with Einstein you download one big file that you use parts of for every unit you crunch until you are done with it. Then Einstein sends you another big file, this cuts down o nthe need to send and receive files every other minute. The 'request' to delete it is telling Boinc to delete the file but your OS will not delete a file that is in use, so it might not be immediately deleted, but it will be shortly.