<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hello All,
<div class=""><br class="">
</div>
<div class="">So far there’s been no complaints to hold this up. Unless that changes,
<b class=""><font color="#00ff00" class="">the plan is to do the flip tomorrow, Thursday, January 16, at 10:00 AM</font></b>.</div>
<div class=""><br class="">
</div>
<div class="">Here’s the final details:</div>
<div class=""><br class="">
</div>
<div class="">1. All our existing, top-level /volatile directories and their data will be remounted/renamed with “_old” suffixes. These will remain available for at least 1 month, but read-only. For example:</div>
<div class=""><br class="">
</div>
<div class="">/volatile/clas12 -> /volatile/clas12_old<br class="">
/volatile/clas/clase1 -> /volatile/clas/clase1_old<br class="">
/volatile/hallb/prad -> /volatile/hallb/prad_old<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">2. The new filesystem will replace the old one, with all top-level directories and their permissions intact, but empty with *no* contents.</div>
<div class=""><br class="">
</div>
<div class="">3. We then move any data we want from the old filesystem to the new one, recreate directory structures, etc.</div>
<div class=""><br class="">
</div>
<div class="">After no less than one month, the old filesystem will be deleted/drained (with a reminder email a ~week in advance) and returned to the disk pool for a further increase. To expedite that, us deleting our data on the old filesystem in advance
will help.</div>
<div class=""><br class="">
</div>
<div class="">-Nathan</div>
<div class=""><br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">On Jan 13, 2020, at 20:14, Nathan Baltzell <<a href="mailto:baltzell@jlab.org" class="">baltzell@jlab.org</a>> wrote:<br class="">
<br class="">
Hello Everyone,<br class="">
<br class="">
JLab's Scicomp is almost ready to switch Hall-B's Lustre filesystems at /volatile to new hardware, which should give us a *very* significant increase in disk space.<br class="">
<br class="">
However, the proposed transition will not be completely transparent to users with existing data on /volatile. See below for details.<br class="">
<br class="">
The earliest possible date for this is January 16, Thursday of this week. The next option would be next Tuesday, January 20, after the long weekend.<br class="">
<br class="">
This transition ideally applies to all these, and everything they contain, in one shot:<br class="">
<br class="">
/volatile/clas12<br class="">
/volatile/hallb<br class="">
/volatile/clas<br class="">
<br class="">
The proposed transition minimizes downtime and system overhead, but will *not* automatically replicate anyone's existing /volatile data to the new filesystem:<br class="">
<br class="">
1. The old /volatile directories above will be renamed/remounted as /volatile-old (or a similar name), become *read-only*, and remain readable for ~one month (similar to our current lifetime on /volatile).<br class="">
<br class="">
2. The new /volatile filesystem will replace the old one, with all quota-level directories and permissions replicated, but sub-directories left to us to recreate as needed.<br class="">
<br class="">
3. We can then copy data from /volatile-old to /volatile if we want to, or leave it there (and keep reading it) until it is deleted in a ~month.<br class="">
<br class="">
I'm not aware of any production accounts currently running long batch workflows using /volatile. It will be good to minimize this transition's impact (and get a huge increase in disk space), so please let me know if you have any considerations, concerns, etc
about this.<br class="">
<br class="">
There will be a followup email with the final date and details ...<br class="">
<br class="">
Regards,<br class="">
Nathan<br class="">
</blockquote>
<br class="">
</div>
</body>
</html>