Under Ubuntu-based systems, is it possible that disk usage be done in another drive than the one the operating system is installed in?

I've found some threads, but has there been new developments? The community is in need for a tutorial, as lots are users are turning away from the project because of this. It could really contribute to its longevity...

http://boinc.berkeley.edu/dev/forum_thread.php?id=8857
http://boinc.berkeley.edu/dev/forum_thread.php?id=9631

There used to be the <data_dir>path</data_dir> tag which could be put in the cc_config.xml, but unfortunately it was taken out [to include the wiki, not even telling as from when it is deprecated]. Though I left it alone in my config, it gives a 'not recognized' since longer... v7 probably.

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

Preliminary Change Log 7.4.23 -> 7.4.24

client: remove <data_dir> option from cc_config.xml

This leads to confusion; e.g. if you do "read config files" it will look for cc_config.xml in the new directory, not find it, and set default options. Also, log files end up in old directory. Also, gui_rpc_auth.cfg will be in new directory, and the Manager won't look there. Source

---

Under Ubuntu-based systems, is it possible that disk usage be done in another drive than the one the operating system is installed in?

That's been answered in the first thread you're referring to.

1. Move the data directory which should be at /var/lib/boinc-client by default. MAKE SURE TO KEEP OWNERS AND PERMISSIONS.
2. Edit /etc/default/boinc-client accordingly.

Don't put the hamster into the microwave oven. Don't move ${PROGRAM}'s data directory while ${PROGRAM} is running.

I've found some threads, but has there been new developments?

What new developments? Is it really worth the effort to make a simple two-step process even simpler? Besides, the UI would be completely overloaded if it could do everything you'd ever want to do.

The community is in need for a tutorial, as lots are users are turning away from the project because of this. It could really contribute to its longevity...

No need to be so dramatic.

Another lower level option to follow might be, follow the approach taken by @bugmenot, leaving everything as as-is, but creating a mount point for /var/lib/boinc-client, pointing at the HDD directory. See Problems moving Linux BOINC client directory

I think i would probably follow that route, but mount at startup in fstab.

To reduce the chances of strangeness, let all running tasks complete and accept no new ones.

As others have mentioned, boinc-client must be stopped, keep ownerships and permissions exactly right, and be certain the old directory is removed or renamed so no longer visible to boinc. Check you do not create a new host ID, if so, you should be able to merge it with the old one.

Good luck.

It's better to move /var/lib/boinc-client to new location and then make it a symlink to the new location. That way you don't need to fix the other parts of the system that expect /var/lib/boinc-client to exist and to be BOINC's data directory.

lots of drama. :)

thanks to all; this will be helping many!

Preliminary Change Log 7.4.23 -> 7.4.24

client: remove <data_dir> option from cc_config.xml

This leads to confusion; e.g. if you do "read config files" it will look for cc_config.xml in the new directory, not find it, and set default options. Also, log files end up in old directory. Also, gui_rpc_auth.cfg will be in new directory, and the Manager won't look there. Source

Maybe semantics, yes the tag was eventually 'removed', but was disabled since much much longer.

With the LocutusofBorg build [my recommendation to use], the cc_config is symlinked from the data_dir to /etc/boinc-client/cc_config.xml [as are several more 'user' config files incl. gui_rpc_auth.cfg]. So when moving the directory, it would still be looking at the correct cc_config with <data_dir>.

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

Maybe semantics, yes the tag was eventually 'removed', but was disabled since much much longer.

Semantics again, but I think I'd say 'broken' rather than 'disabled'. I don't think the implications were thought through properly when BOINC's directory structure was split from a single combined directory into separate program and data directories: I rather doubt it ever worked properly after that, but not many people tried to use it.

With the LocutusofBorg build [my recommendation to use], the cc_config is symlinked from the data_dir to /etc/boinc-client/cc_config.xml [as are several more 'user' config files incl. gui_rpc_auth.cfg]. So when moving the directory, it would still be looking at the correct cc_config with <data_dir>.

Which would be fine for Linux, but impossible to work with in Windows. Here the path to the data directory is set in the registry, which is the first place BOINC will look in for all its files, including the cc_config.xml file. When the path to this data directory is changed in this same cc_config.xml file, and the whole of the data directory including this cc_config.xml file lives in the path set in the cc_config.xml file, how then will BOINC under Windows ever find it in the first place? (Yes, re-read that 4 times to find what I said :))

By the way, anyone tried if the --path tag on the BOINC binary went the same way?

---

Quite out of topic, but an alternative to changing location to prevent SSD wear would be to use VirtualBox to create a virtual machine (VM) in the partition of another disk. The downside is that a VM is not really compatible with using the GPU for crunching, but here, for example, I realized a) most WCG projects at the moment do not support GPU crunching; and b) SETI does support GPU crunching but is not really disk intensive so it could well be ran out of the VM with one core and the GPU dedicated to it.

lots of drama. :)

thanks to all; this will be helping many!

The way I usually write documentation is to double and triple check everything, try to come up with everything the reader might have different vs. the system I'm writing on (and document all that), try to anticipate anything the reader might do wrong and so on. And if it's some step-by-step kind of documentation I usually end up going back and splitting each step into two or three or even more steps, and then splitting those into even more steps. It's ridiculously time consuming.

I don't think this question comes up often enough to make it worth spending the time to write a tutorial. So far it hasn't taken that much time to write instructions for one person at a time. There has been some discussion over at Seti@home about SSD longevity and seems people have come to the conclusion that with modern SSDs running BOINC isn't enough to kill them. So there'll be even less need for a tutorial.

Now, were you in need of help with moving the data directory or were you just idly wondering if there was a tutorial?

More so just wondering if the steps to move could be explained. But they have. And what I had in mind when I used the term "tutorial" was not that polished of an explanation, as the current ones seem to do the job plenty.

P.S.: my mistake in browsing the other thread was that discerning no solution had been achieved, which, after all, is not the case. Plus at the time I thought (a) current-generation SSDs were more fragile than they actually are; and (b) some projects (such as SETI@home) were more write intensive than they are.

Thread solved!