Sherlock changelog

Sherlock changelog

www.sherlock.stanford.edu

Storage quota units change: TB to TiB

by Kilian Cavalotti, Technical Lead & Architect, HPC
Following in Oak footsteps, we’re excited to announce that Sherlock is adopting a new unit of measure for file system quotas. Starting today, we're transitioning from Terabytes (TB) to Tebibytes (TiB) for all storage allocations on
Improvement
Data

Sherlock goes full flash

by Stéphane Thiell & Kilian Cavalotti, Research Computing Team
Data
Hardware
Improvement
What could be more frustrating than anxiously waiting for your computing job to finish? Slow I/O that makes it take even longer is certainly high on the list. But not anymore! Fir, Sherlock’s scratch file system, has just undergone a major
Sherlock goes full flash

Final hours announced for the June 2023 SRCF downtime

by Kilian Cavalotti, Technical Lead & Architect, HPC
Maintenance
Announce
As previously announced, the Stanford Research Computing Facility (SRCF), where Sherlock is hosted, will be powered off during the last week of June, in order to safely bring up power to the new SRCF2 datacenter. Sherlock will not be
Final hours announced for the June 2023 SRCF downtime

A new tool to help optimize job resource requirements

by Kilian Cavalotti, Technical Lead & Architect, HPC
It’s not always easy to determine the right amount of resources to request for a computing job. Making sure that the application will have enough resources to run properly, but avoiding over-requests that would make the jobs spend too much
Documentation
Scheduler
Improvement

SRCF is expanding

by Kilian Cavalotti, Technical Lead & Architect, HPC
Maintenance
In order to bring up a new building that will increase data center capacity, a full SRCF power shutdown is planned for late June 2023. It’s expected to last about a week, and Sherlock will be unavailable during that time.
SRCF is expanding

ClusterShell on Sherlock

by Kilian Cavalotti, Technical Lead & Architect, HPC
Software
New
Ever wondered how your jobs were doing while they were running? Keeping a eye on a log file is nice, but what if you could quickly gather process lists, usage metrics and other data points from all the nodes your multi-node jobs are running
ClusterShell on Sherlock

Job #1, again!

by Kilian Cavalotti, Technical Lead & Architect, HPC
This is not the first time, we’ve been through this already (not so long ago, actually) but today, the Slurm job id counter was reset and went from job #67043327 back to job #1.
Event
Scheduler