<html><head></head><body>I implemented a cron job to delete scratch data created over 30 days ago. That didn't go well with the people who were eating up all space and not paying for hard drives. So I gave them a way to extend particular areas up to 90 days. Day 91 it was deleted. So they wrote a script to copy their internet archive around every 2 weeks to keep the creation date below the 30 day cut off. So I shrunk the partition of /scratch to about 10G larger than was currently in use. He couldn't do his runs to graduate in time without cleaning up his mess. It also pissed off other people and they yelled at him when I gave my report of who the storage hog was.<br><br><div class="gmail_quote">On October 27, 2015 11:24:48 AM EDT, Todor Fassl <fassl.tod@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">I dunno. First of all, I don't have any details on what's going on on <br />the HPC cluster. All I know is the researcher says he needs to back up <br />his 3T of scratch data because they are telling him it will be erased <br />when they upgrade something or other. Also, I don't know how you can <br />have 3T of scratch data or why, if it's scratch data, it can't just be <br />deleted. I come across this all the time though. Researchers pretty <br />regularly generate 1T+ of what they insist is scratch data.<br /><br />In fact, I've had this discussion with this very same researcher. He's <br />not the only one who does this but he happens to be the guy who i last <br />questioned about it. You know this "scratch" space isn't backed up or <br />anything. If the NAS burns up or if you type in the wrong rm command, <br />it's gone. No problem, it's just scratch data. Well, then how come I <br />can't just delete it when I want to re-do the network storage
device?<br /><br />They get mad if you push them too hard.<br /><br /><br /><br /><br /><br />On 10/27/2015 09:45 AM, Jim Kinney wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Dumb question: Why is data _stored_ on an HPC cluster? The storage for<br /> an HPC should be a separate entity entirely. It's a High Performance<br /> cluster, not a Large Storage cluster. Ideally, a complete teardown and<br /> rebuild of an HPC should have exactly zero impact on the HPC users'<br /> data. Any data kept on the local space of an HPC is purely scratch/temp<br /> data and is disposable with the possible exception of checkpoint data<br /> and that should be written back to the main storage and deleted once the<br /> full run is completed.<br /><br /> On Tue, 2015-10-27 at 08:33 -0500, Todor Fassl wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8;
padding-left: 1ex;"> One of the researchers I support wants to backup 3T of data to his space<br /> on our NAS. The data is on an HPC cluster on another network. It's not<br /> an on-going backup. He just needs to save it to our NAS while the HPC<br /> cluster is rebuilt. Then he'll need to copy it right back.<br /><br /> There is a very stable 1G connection between the 2 networks. We have<br /> plenty of space on our NAS. What is the best way to do the caopy?<br /> Ideally, it seems we'd want to have boththe ability to restart the copy<br /> if it fails part way through and to end up with a compressed archive<br /> like a tarball. Googling around tends to suggest that it's eitehr rsync<br /> or tar. But with rsync, you wouldn't end up with a tarball. And with<br /> tar, you can't restart it in the middle. Any other ideas?<br /> Since the network connection is very stable, I am thinking of suggesting<br /> tar.<br /><br /> tar zcvf - /datadirectory | sshuser@backup.server
<mailto:user@backup.server> "cat > backupfile.tgz"<br /><br /> If the researcher would prefer his data to be copied to our NAS as<br /> regular files, just use rsync with compression. We don't have an rsync<br /> server that is accessible to the outside world. He could use ssh with<br /> rsync but I could set up rsync if it would be worthwhile.<br /><br /> Ideas? Suggestions?<br /><br /><br /><br /> on at the far end.<br /><br /> He is going to need to copy the data back in a few weeks. It might even<br /> be worthwhile to send it via tar without uncompressing/unarchiving it on<br /> receiving end.<br /><br /><br /><br /><hr /><br /> Ale mailing list<br /> Ale@ale.org <mailto:Ale@ale.org><br /> <a href="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</a><br /> See JOBS, ANNOUNCE and SCHOOLS lists at<br /> <a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a><br /></blockquote><br /> --<br />
James
P. Kinney III<br /><br /> Every time you stop a school, you will have to build a jail. What you<br /> gain at one end you lose at the other. It's like feeding a dog on his<br /> own tail. It won't fatten the dog.<br /> - Speech 11/23/1900 Mark Twain<br /><br /> <a href="http://heretothereideas.blogspot.com">http://heretothereideas.blogspot.com</a>/<br /><br /><br /><br /><hr /><br /> Ale mailing list<br /> Ale@ale.org<br /> <a href="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</a><br /> See JOBS, ANNOUNCE and SCHOOLS lists at<br /> <a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a></blockquote><br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>