I have looked for at least 1/2 hour and I don't find a discussion of this question anywhere in the BOINC Docs or forums. If I have missed something, please direct me there. Thank you. ---

I have 2 machines each with 2 Linux and 1 WinDoze partition on each machine. That's SUSE, Mandriva and Win98 on one and SUSE, Mandriva, WinXP on the other. Though both machines run continuously, the amount of time I spend on any partition varies considerably. I may not use a partition for months at a time. Consequently, if I have unfinished BOINC jobs on a partition which is unused for a long time, the deadlines expire and I lose credit for the work. Plus it's just darned inefficient to have 99% of the work on a job evaporate.

Most all of my disk real estate is accessible to all partition OS'. Certainly all the BOINC files on all the partitions are accessible to all the running systems.

Is there a way for Linux and Win OS' to share data files so when I reboot from one partition (and OS) to another, the same jobs (even if not in the same order) continue to run without missing deadlines and expiring?

At my first, cursory glance it appears that. after the first BOINC installation in the first partition is up and running, that by deleting the 'slot' and 'projects' directories of subsequent installations and replacing these 2 directories with links (shortcuts) to the same, respective, original directories in the first installation, that the subsequent installations would continue to process the same group of jobs when partitions (and OS') are changed.

My second thought after another quick side by side comparison of the Linux vs Win BOINC files is that there may be some scheduling files in the BOINC installation directories that would then NOT be shared by this first trick, but the next thing that occurred to me is that, as Win and Linux program files are easily identified by their respective OS', if the first, shortcuts, trick doesn't work, then it might just be possible to install the WinXP and the Linux files to the same directory. Non unique files would just be overwritten and used. Unique files would be recognized and used by the appropriate systems.

Has anyone tried this? Does anyone have any experience with this question?

I have done this sort of thing before (and surprisingly often it works) but as I am relatively new to Linux, at this particular moment I am loath to do something which may destroy a partition or lose any more work.

At this point it seems more prudent to ask for help, though if help is not forthcoming I know I will begin to experiment as soon as I feel that my Linux systems (and my knowledge of my Linux systems) are robust enough to withstand a little hacking.

Thanks.

No, that's not possible.

• The client keeps some information about workunits, like their input files and applications. The application file name is different for each platform. There may even be more or less files that make up an application for a particular platform. For example, I think SETI@Home statically links fftw on Linux, but uses libfftw-someversionnumber.dll on Windows.
  
• Slots have fake "soft links" to the application files in the project directory. These also would need modifying when swapping platforms.
  
• Each OS on your disk is considered a different computer by the project. I think projects won't let you download work from a "computer" and upload it from another.
  
• Intermediate files kept by the project application aren't guaranteed to be portable across platforms. They could very well be totally incompatible.
  

---

I had a plan for a client modification that would let you share workunits between platforms, solving all but the last problem. Somebody told me sharing between platforms isn't a very common case, and that my idea was not worth the effort.

---

No, that's not possible.

(Snip)


• Each OS on your disk is considered a different computer by the project. I think projects won't let you download work from a "computer" and upload it from another.
  

Thanks. On problems like this I try to work from the conceptual to the practical because most often things wash out in your head with much less effort than when banging out details on the keyboard.

As I was typing my question, I knew there was one specific thing that I had in mind that seemed to raise a red flag about the possibility of what I hoped to do but I kept forgetting what it was. It is this point you have brought up: Viewing one's results by machine it becomes apparent that the project does in fact consider different operating systems on the same machine as different machines.

A consideration in favor of my project is that, at least for purposes of your statistics, various machines can be merged, but the final question would remain: Even if you got all the files on the client to function, what would the project server software think when it noticed that a work unit had been downloaded to machine A and the result was received back from machine B. Might not the project consider these results as suspect and discard them? That would be among the most horrific of situations. To have all your computational results rejected without your knowing which would result in your systems happily continue cranking out results, only to have them all discarded as suspect. Yikes, Sikes!!!

*Intermediate files kept by the project application aren't guaranteed to be portable across platforms. They could very well be totally incompatible.

Another consideration. All this could easily be tested by a few links and copying one installation over another.

All this would be a 10 minute job on the WinDoze machines but I don't feel confident enough of my Linux abilities to fool around like this yet. Yet. The Linux systems are just running so smoothly at this point. I am enjoying them so much I don't want to rock the boat.

---

I had a plan for a client modification that would let you share workunits between platforms, solving all but the last problem. Somebody told me sharing between platforms isn't a very common case, and that my idea was not worth the effort.

I would certainly agree that writing a client modification is a long way to go for this small result.

My biggest consideration at first was trying to find out how to have applications startup on boot because it was taking me at least 10-15 minutes to remember to start BOINC after a reboot. Sometimes I only kept the partition in operation for 10-20 minutes and I lost the time. It was so nice when I stumbled across the GUI application launcher.

I thought Use Clusters!

Holy Grail?

So you have two machines each one a dual booter.

If you have a cluster master node (third machine) set up to BOINC in a way that it serves the SciApp to a machine over the LAN where it boots as if it were another processor in a multicore system.

Transparent would be the OS on the client box.

When the process shuts down the partial result is already on the master node physical volume and available for reassignment and the SciApp just evaporates.

Huh? Why not?

---

I would certainly agree that writing a client modification is a long way to go for this small result.

Well, it wasn't really a client modification. More like an idea for a feature I would add when/if I write an alternate client implementation from scratch xD

---

I would certainly agree that writing a client modification is a long way to go for this small result.

Well, it wasn't really a client modification. More like an idea for a feature I would add when/if I write an alternate client implementation from scratch xD

I see. Unfortunately, I don't write much code. I can if my life depends on it but while I certainly qualify as an expert operator, I'm a writer and not an IT person. I just like to see things get done as easily as possible. So while there is still a small (very) chance I'll try an experiment with some shortcuts and overwrites, for the foreseeable future I'm just going back to doing what I was doing. I'll let my work needs determine when and what partition I boot and let the loss of work fall where it may.

I do think I'll have to drop predictor or climatePredictor, whichever one it is that farms out the 2000 hour jobs so I avoid having 1999 hour losses. Other than that, while I like efficiency, sometimes the overzealous pursuit of efficiency can become just plain wasteful.

Thanks also to Sekerob and Guy above for their posts. As I say, I'm not really looking for that much trouble.

I'm a writer and not an IT person.

I thought you were a French politician!

Nobody running ClimatePrediction models needs to lose them. If you look at the CPDN project READMEs, third section here, you'll find there's an entire category about how to regularly back up the BOINC folder contents so that if a model does crash, a backup can be restored and the model continued. The only models that one occasionally can't avoid losing are the few that turn out to be flawed.

I have 2 machines each with 2 Linux and 1 WinDoze partition on each machine. [...] Though both machines run continuously, the amount of time I spend on any partition varies considerably. I may not use a partition for months at a time. Consequently, if I have unfinished BOINC jobs on a partition which is unused for a long time, the deadlines expire and I lose credit for the work. Plus it's just darned inefficient to have 99% of the work on a job evaporate.

Most all of my disk real estate is accessible to all partition OS'. [...] Is there a way for Linux and Win OS' to share data files so when I reboot from one partition (and OS) to another, the same jobs (even if not in the same order) continue to run without missing deadlines and expiring?

Because of all problems, mentioned by others, I'd recommend you creating one virtual (Linux or Windows) machine on each of your two computers and running Boinc off the virtual machine from whichever OS you just boot.

Peter