[PRad] preparations for new Hall B /volatile

Nathan Baltzell baltzell at jlab.org
Wed Jan 15 10:24:29 EST 2020

Hello All,

So far there’s been no complaints to hold this up.  Unless that changes, the plan is to do the flip tomorrow, Thursday, January 16, at 10:00 AM.

Here’s the final details:

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:

/volatile/clas12 -> /volatile/clas12_old
/volatile/clas/clase1 -> /volatile/clas/clase1_old
/volatile/hallb/prad -> /volatile/hallb/prad_old

2. The new filesystem will replace the old one, with all top-level directories and their permissions intact, but empty with *no* contents.

3. We then move any data we want from the old filesystem to the new one, recreate directory structures, etc.

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.


On Jan 13, 2020, at 20:14, Nathan Baltzell <baltzell at jlab.org<mailto:baltzell at jlab.org>> wrote:

Hello Everyone,

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.

However, the proposed transition will not be completely transparent to users with existing data on /volatile.  See below for details.

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.

This transition ideally applies to all these, and everything they contain, in one shot:


The proposed transition minimizes downtime and system overhead, but will *not* automatically replicate anyone's existing /volatile data to the new filesystem:

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).

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.

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.

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.

There will be a followup email with the final date and details ...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/prad/attachments/20200115/fc99cef5/attachment.html>

More information about the PRad mailing list