LHC@home

If Ben or colleagues are looking in, what is the situation re the Deleter?

I have noticed that no results have been deleted since we changed servers. Is this simply bec you still need the results online for some reason, or is the result deleter broken? I have a fantasy that the server will fill up and then grind to a halt...

R~~

---

I was hoping that had something to do with all the pending results still showing up. :-( Maybe not. Can't complain though, I only have about 50. This bloke has 216!! That's about 1,080 rows still filling up the database form a fault in one user's part of the project.

---

Click here to join the #1 Aussie Alliance on LHC.

file_deleter is not even in the daemon list, so it's not set up to run at all!

---

That's about 1,080 rows still filling up the database form a fault in one user's part of the project.

Clearing that result list is a separate problem. What the file deleter does is delete *files*. This means the input and output files for those 200,000 results are still eating server diskspace!!! Unless they are removing them manually.

---

Clearing that result list is a separate problem. What the file deleter does is delete *files*. This means the input and output files for those 200,000 results are still eating server diskspace!!! Unless they are removing them manually.

I had naively assumed that the deleter would *also* update the db to keep the two in sync -- clearly it has to read data from the db in order to know which files are still needed.

If you are telling me I was mistaken, well it's not the first time that has happened ;) But then it seems at first sight like it's a rather odd design to remove the files and not remove the db entries that refer to them.

And if not, then it is not clear to me whether the figure for results waiting for deletion (on the server status page, and in Scarcrows graphs) refers to results listed in the db, or results with files on the file server.

R~~

Clearing that result list is a separate problem. What the file deleter does is delete *files*. This means the input and output files for those 200,000 results are still eating server diskspace!!! Unless they are removing them manually.

I had naively assumed that the deleter would *also* update the db to keep the two in sync -- clearly it has to read data from the db in order to know which files are still needed.

file_deleter reads the database first, and deletes output files from completed results, and input files from workunits with no other unsent/in progress results remaining. Workunits and results are kept in database, they can be archived (into compressed XML) and deleted using a different program (db_purge). They are useful to have crash statistics and other stuff (since stderr is kept).

And if not, then it is not clear to me whether the figure for results waiting for deletion (on the server status page, and in Scarcrows graphs) refers to results listed in the db, or results with files on the file server.

Workunits/Results ready to delete = Workunits/Results waiting for file_deleter to do something about them. That is, delete input/output files.

EDIT: I think this would be something more urgent to take care of.

---

EDIT: I think this would be something more urgent to take care of.

agree