Scaling AI Storage: Azure Managed Lustre excels in MLPerf Storage v3.0
In large scale AI clusters storage is responsible for delivering training data fast enough to keep accelerators busy and completing checkpoint saves and recoveries quickly enough to avoid costly stalls. MLPerf Storage is an industry-standard benchmark developed by MLCommons that reproduces the I/O patterns of different stages of AI pipelines covering training, checkpointing, context cache and vector database scenarios, reporting how efficiently a storage system can sustain the I/O rates required by the workload maximizing accelerators throughput without introducing bottlenecks. Azure submitted results in the MLPerf Storage v3.0 round, and its training and checkpointing results rank as the top submissions among major hyperscalers, in both demonstrated scale and sustained performance. In checkpointing, Azure Managed Lustre reached 642.2 GiB/s of write throughput and 489.6 GiB/s during recovery, showing the highest peak write performance for both the 405B and 1T model configurations among hyperscalers and public cloud submissions. In training, Azure Managed Lustre demonstrated the ability to sustain the required accelerator utilization with hundreds of GiB/s across five different tiers and file systems ranging from 40 TiB to the largest system presented in the submission, a 25 PiB file system in a single POSIX namespace. These peer-reviewed results demonstrate that Azure Managed Lustre is a service built for the scale AI now demands and that can sustain the storage performance required to keep AI accelerators highly utilized across different stages of AI workloads. What the Benchmark Measures MLPerf Storage answers one question: how effectively can a storage system keep AI accelerators highly utilized and operating efficiently? In a modern AI cluster, accelerators are among the most constrained and expensive resources. Every second they wait for training samples or checkpoint I/O reduces the productive value of provisioned compute. MLPerf Storage isolates the storage path and measures whether it can sustain the I/O rate required by a representative AI workload. The benchmark has an OPEN and a CLOSED division. In the CLOSED division, workload code and benchmark parameters are standardized, while submitters may tune the storage system within the benchmark rules. This constraint reduces variation outside the storage path and makes results more directly comparable across submitters. Azure submitted every reported result in CLOSED division. Training category The training category evaluates whether a storage system can sustain the data-delivery rate required to keep simulated accelerators utilized throughout an extended time window, rather than only demonstrating a short burst of peak throughput. Why it matters: accelerators represent the widest portion of an AI cluster’s cost, and storage stalls reduce the productive value of provisioned compute. Because the benchmark evaluates simulated accelerator utilization rather than raw bandwidth alone, a passing score indicates that the storage path sustained the required workload’s data-delivery requirements without becoming a bottleneck. Checkpointing category The checkpointing category measures how quickly a storage system can write model state at a synchronization barrier and read that state during recovery, including recovery on different client hosts. These operations model the storage demands involved when a distributed training job resumes after a failure. Why it matters: checkpoint writes pause progress across a distributed training job, making checkpoint duration a shared overhead for the cluster with accelerator stalling. Faster writes let teams checkpoint more often and reduce the work at risk without significantly affecting accelerator utilization, while faster recovery reads shorten the time required to resume a disrupted job. What Was Tested Every result used Azure Managed Lustre, a managed parallel file system that presents clients with a single POSIX namespace. Testing covered five service tiers and file-system capacities from 40 TiB to approximately 25 PiB. MLPerf Storage generates workload I/O from standard client nodes rather than GPU nodes, and the submission used publicly available Azure virtual machine SKUs, network configurations, deployment patterns, and service interfaces. Results were produced across multiple Azure regions using configurations available to customers today. Together with the published system descriptions and configuration details, these results provide a practical reference for evaluating Azure Managed Lustre performance. In the training category, Azure Managed Lustre sustained throughput and maintained simulated accelerator utilization above 90% for five consecutive hours on the UNET3D workload with 13 distinct system configurations. The submitted configurations ranged from tens of TiB to tens of PiB and delivered sustained throughput in the hundreds of GiB/s. The five-hour result demonstrates predictable storage performance over an extended benchmark run rather than a short-lived burst. AMLFS delivers target performance across all service tiers, enabling customers to optimize capacity and performance for each workload without compromising accelerator utilization, as shown in Figure 1. Figure 1, AMLFS UNET3D Training performance (B200) across different bandwidth density configurations Most relevant to highlight is how Azure Managed Lustre delivers at more than 96% the nominal bandwidth density across all tiers tested in training category, and how the results, taking AMLFS 125 as a tier, scale almost linearly increasing the number of accelerators (Figure 2). Figure 2, AMLFS UNET3D Training performance (B200) delivered bandwidth density and scalability. In checkpointing category, the benchmark covered four Llama3 scales, from an 8B model with a 105 GB checkpoint to a 1T-class model with an 18 TB checkpoint, and Azure submitted results for all four. Within those benchmark rules, Azure Managed Lustre reached up to 642 GiB/s of checkpoint write throughput and up to 490 GiB/s during recovery, enabling the tested checkpoints to be written and restored in tens of seconds or less. For checkpointing, AMLFS 125 has been picked as example tier, but similar results are expected, as demonstrated in the training scenario, with different AMLFS tiers. Figure 3, AMLFS checkpointing performance across different model size. The published results give the AI community a peer-reviewed view of Azure Managed Lustre under modern AI workloads, including sustained throughput, predictable performance, and deployment choices across service tiers. Full system descriptions and performance numbers are available in the MLCommons MLPerf Storage v3.0 results tables. Five Tiers, 20 to 500 MB/s per TiB, One Right Size for Every AI Workload Results span five Azure Managed Lustre service tiers, from 20 MB/s per TiB to 500 MB/s per TiB, showing how the tested performance extends across the range of configurations available for demanding AI workloads. That breadth is deliberate because AI infrastructure requirements vary by model size, accelerator count, data volume, and I/O pattern; there is no single correct storage configuration. Results across five tiers show how customers can balance throughput, capacity, and cost as models, datasets, and clusters grow. Correct sizing can reduce storage bottlenecks and shorten time to results while retaining the durability and resiliency of a managed cloud file system. Getting Started with Azure Managed Lustre To evaluate Azure Managed Lustre for an AI or HPC workload, review the Azure Managed Lustre documentation for service capabilities, planning guidance, and deployment options. Then use the Azure portal deployment guide to configure and create a file system. For deployment examples, explore the AI Infrastructure on Azure GitHub repository. It provides reference architectures, best practices, and templates for AI and HPC environments, including examples built with Azure CycleCloud and Azure Kubernetes Service. Together with the resources below, these examples show how Azure Managed Lustre can serve as a high-performance shared storage layer for AI workloads. Learn More Azure Resources Azure Managed Lustre Azure Managed Lustre MLPerf Storage v3.0 results Azure AI Infrastructure AI Infrastructure on Azure GitHub repository Azure CycleCloud Azure Kubernetes Service MLPerf Resources MLCommons MLPerf Storage MLPerf Storage GitHub repository Benchmark MLPerf Storage | MLCommons V3.0 Results GitHub Repository of MLPerf Storage v3.0 results
How to get rid of old Onenote files in Onedrive
I've been using Onenote for many, many years and over that time I have collected several unused files that seem to be un-deletable on Onedrive. I have deleted some of them within Onedrive from time to time but the names seem to remain. Here is what I see. When I click "Files" in One drive I see folders and under that documents which contains my only current Onenote database. The one I use. But, then I click "home" and see six old unused data base files that cannot be deleted. When I click on some of them the screen says "Sorry, something went wrong - Item may have been deleted by another person" Another file will say "This item might not exist or has been deleted". I am the only one who uses this account. I'm not sure what HOME is or what its function is as it doesn't show any folders or files that are active. It only shows these abandoned Onenote databases that nothing can be done with. So, Is there a way to clean this up or is it just not worth the effort. Since I don't know what the function of Home is I'm not sure if it matters. Thanks for any enlightenment.
OneDrive suddenly became empty after university storage policy change Is recovery still possible?
Hello everyone, I am looking for technical guidance regarding a serious OneDrive for Business issue under Microsoft 365 Education. Environment - Microsoft 365 Education tenant. - University-managed account. - OneDrive for Business. - My account is still active and I can sign in normally. What happened On July 16, 2026, I signed into my OneDrive and discovered that my entire "My files" folder was empty. I verified the following: - I am signed into the correct account. - "My files" is completely empty. - The OneDrive Recycle Bin is empty. - "Restore your OneDrive" does not show any mass deletion event. - My OneDrive site is accessible, but there are no files. - I unfortunately do not have a complete local backup. A few days later, my university informed students that they had reduced the OneDrive storage quota from 5 TB to 30 GB due to a Microsoft/provider policy update. I suspect my OneDrive contained more than 30 GB because I had stored backups from my previous computer together with years of academic, personal and work files. However, I would like to understand whether exceeding the new storage quota could actually cause an existing OneDrive site to appear completely empty, or whether this suggests another issue such as: - OneDrive reprovisioning - Site replacement - License reassignment - Site deletion - Storage migration - SharePoint issue - Other administrative problem The university initially described this as a temporary Microsoft incident, but later told me that the files had been deleted because of the OneDrive application, without providing any technical explanation. I have already asked the university IT department to investigate: - Deleted Sites in SharePoint Admin Center - Second-stage Recycle Bin - Retention policies - Previous OneDrive site - Licensing history - Possible restore options My question to Microsoft experts is: 1. Can a storage quota reduction (5 TB → 30 GB) ever make an existing OneDrive appear completely empty? 2. Are there other administrative scenarios that could produce this behavior while leaving the account active? 3. Is there anything specific I should ask my Microsoft 365 administrator to verify that is commonly overlooked? Any guidance would be greatly appreciated because these files represent several years of academic, professional and personal work. Thank you very much.
ONEDRIVE WEB VERSION
I use the OneDrive web version because I don't want to install the OneDrive app, as I have very little space on my C: drive. So my question is: I copied all my music from my PC to OneDrive via the web a few months ago, but it has all disappeared again! I had to do this last year as well because it had all disappeared then too. Why do I have to keep doing this? It takes a very long time because my broadband is very slow. Luckily, I have a backup on an external hard drive, but I don't want to have to keep doing this! Does anyone know why my Music folder keeps disappearing from my OneDrive (web)?Cut Your Azure Blob Storage Bill in Half: A Practical Walkthrough of Object Storage TCO
Hello Folks! If you have ever opened your monthly Azure invoice, stared at the object storage line, and quietly wondered how it grew so much, this one is for you. At the Microsoft Azure Infra Summit 2026, Benedict Berger and George Trossell from the Azure Storage Engineering team walked through a real customer scenario and showed how to bring that bill down without touching a single application. 📺 Watch the session: Why IT Pros Should Care Storage is one of those services we configure once at account creation, then never revisit. Redundancy, default tier, lifecycle rules. All decided on day one, then forgotten. Meanwhile, applications get built on top, dashboards get wired up, and the bill keeps climbing in a department nobody really audits. Here is what you get when you make storage TCO a first-class part of your operating model: A defensible understanding of capacity, transactions, and data retrieval charges (the three real cost drivers). Fewer surprise spikes when a cool tier read pattern runs hotter than expected. Cost optimization that runs on its own, instead of a quarterly cleanup project nobody volunteers for. Storage standards baked into your Infrastructure as Code, so cost-efficient defaults travel with every new account. In short, this is one of the highest-leverage cost levers you have in Azure. And unlike compute right-sizing, you can act on most of it from the portal in an afternoon. What Storage TCO Actually Means on Object Storage, a Technical Overview When Benedict and George talk about Total Cost of Ownership on Azure Blob Storage, they mean four moving parts: Capacity. The per-gigabyte cost of the data you store, which varies by access tier and by redundancy. Transactions. Every read, write, list, and metadata call against the storage account. Priced in packages of 10,000 operations. Data retrieval. A per-gigabyte fee that applies when you read from cool or cold tiers. It is free on hot. Network egress. The charge for moving data out of an Azure region. The trap most teams fall into is looking only at the per-gigabyte capacity column and picking the cheapest tier they see. That ignores the fact that as data gets cooler, transaction and retrieval costs climb sharply, and cold has a 90-day early deletion penalty that can erase your savings outright. Microsoft Learn documents this trade-off clearly in the access tiers overview, where you can see the minimum retention windows and the relationship between storage cost and access cost across hot, cool, cold, and archive. Redundancy is the other dial. LRS keeps three copies in a single zone. ZRS spreads three copies across three zones in the region. GRS adds an asynchronous secondary in a paired region. The honest tradeoff George highlighted: redundancy protects your data, not your application. If your app is not zone-aware, ZRS alone will not keep you running through a zone outage. And GRS failover is a manual operation in most cases, with the secondary in read-only mode until you stand up new accounts to write into. How It Works, Under the Hood The session walked through a worked transaction example that finally made the math click for me. Picture a Spark job uploading 1,000 parquet files of 5 GB each into the hot tier, using an 8 MB block size. Each 5 GB file is roughly 5,120 MB, divided by 8 MB blocks, which gives 640 put block operations. One additional put block list call commits the upload, so each object costs 641 write operations. Times 1,000 files, that is 641,000 operations, which works out to about 3.52 US dollars in that hour just for writes. Now flip it. Read those same 1,000 files from the cool tier. The transaction count is similar, but you also pay a data retrieval fee on every gigabyte you pull back. That retrieval fee is where most teams get blindsided, because it does not show up on the hot tier at all. Block size matters too. Larger blocks mean fewer transactions per upload. And for small objects (under 128 KB), there is a new wrinkle to plan for: starting July 2026 for existing accounts and already in effect for new accounts created from July 2025, cooler tiers bill a 128 KB minimum object size. That means a 4 KB log file moved to cool gets charged as if it were 128 KB. The fix is either to leave small objects in hot, or bin-pack them into larger objects (a TAR or ZIP, for example) before tiering them down. The Microsoft Learn page on access tier best practices covers packing strategies in detail. Real-World Value, Use Cases, and ROI The customer in the session went from roughly 65,000 US dollars a month to around 25,000. That is not a marketing number, it is what happens when you apply the levers in order: Right-size redundancy. Move non-production and easily reproducible data off LRS in production. Reserve GRS for the workloads where a compliance regulation actually requires a second region. Match tiers to access patterns. Use premium for bursty, latency-sensitive workloads. Hot for active reads and writes. Cool and cold only when you genuinely access the data infrequently and have budgeted for the retrieval fees. Buy reserved capacity for the steady-state portion of your footprint. A one or three year commitment unlocks a discount on block blob capacity. See reserved capacity for Blob storage for terms and tier coverage. Kill wasteful transactions. Replace polling-for-changes with change feed. Replace recurring list-blob loops with a daily or weekly blob inventory report. Use conditional request headers (If-Modified-Since and friends) so reads skip unchanged objects. Pack small objects, or leave them in hot. Either is fine; tiering them down without packing is not. In short, the same scenario, with the same applications, runs at less than half the cost once you actually look at it. Getting Started Here is the order of operations I would follow tomorrow morning: Pull a blob inventory report on your largest storage accounts to see what is actually there: tier mix, object sizes, last modified dates, snapshots, versions. Open the Azure pricing calculator and model your scenario with realistic transaction counts and retrieval volumes. Do not just compare per-GB prices. Audit your redundancy choices against the workload. If an account is LRS in production with no easy way to rebuild the data, change it. Enable Smart Tier on your zone-redundant accounts. New objects start in hot, get demoted to cool after 30 days of inactivity, and to cold after 90, with no charges for tier transitions, early deletions, or data retrieval. Anything accessed gets instantly promoted back to hot. For accounts that cannot use Smart Tier, write a lifecycle management policy. Keep the rules simple at first: tier down after 30 days, archive after 180, expire snapshots and versions on a schedule. Convert one of your existing lifecycle policies to ARM or Bicep, then commit it to source control. Add an Azure Policy that flags any new storage account that does not match your standard. That last step is the one that sticks. As Benedict put it, cost optimization must become part of your system, not an afterthought. Resources Access tiers for blob data, Microsoft Learn Best practices for using blob access tiers, Microsoft Learn Azure Blob Storage lifecycle management overview, Microsoft Learn Optimize costs for Blob storage with reserved capacity, Microsoft Learn Enable Azure Storage blob inventory reports, Microsoft Learn Azure pricing calculator Keep Learning at the Summit Catch the full Microsoft Azure Infra Summit 2026 session playlist here Cheers! Pierre RomanFeeding the GPUs: File Storage for AI and Cloud-Native Workloads on Azure
Hello Folks! If you are running AI workloads on Azure, you have probably learned the hard way that the wrong storage choice can leave a rack of very expensive GPUs sitting idle, waiting for data. In this session during the Microsoft Azure Infra Summit 2026, Wolfgang de Salvador and Reena Shah from the Azure Storage team walked through how Azure Managed Lustre and Azure Files map to the distinct stages of the AI pipeline, and why picking the right file system per stage is one of the highest leverage decisions you will make. 📺 Watch the session: Why IT Pros Should Care You probably did not get into IT to babysit checkpoint writes or debug Hugging Face egress bills at 2 a.m. But that is exactly the kind of work that lands on your plate when storage is not matched to the workload. Here is why MAIS28 matters for the IT pros, platform engineers, and Azure architects in the room: GPU time is the most expensive compute you will ever buy. Slow data loading and slow checkpoints turn that into burned cash. AI workloads are not one workload. Data prep, training, fine-tuning, and inferencing each have a different storage profile. Cloud-native AI on AKS and Azure Container Apps lives or dies on the ReadWriteMany experience. If model loading is slow or shared model caches do not exist, every cold start re-downloads hundreds of gigabytes. Storage choices ripple into security and compliance. Encryption in transit, redundancy, and snapshots are not optional in 2026. In short, this session is for anyone who has to answer the question, “What persistent volume should we use for this AI workload?” and wants a defensible answer. What Azure Brings to the Table, Technical Overview Wolfgang opened with the storage profile of every stage of an AI workflow. Data preparation needs hundreds of petabytes at the best TCO (think Azure Blob Storage as the durable core). Training and fine-tuning need extreme throughput so GPUs stay fed during data loading and so checkpoint writes complete fast. Inferencing needs fast model loads, low-latency KV cache, and grounded data for RAG. One filesystem does not fit all of those at once, and trying to make it fit is where teams overspend. Azure’s answer is a tiered, file-based portfolio that lines up with those stages: Azure Managed Lustre (AMLFS) is a fully managed, accelerator-tier filesystem. It scales to 25 PB of capacity and up to 512 GB/s of throughput, integrates with Azure Blob Storage as the durable core, and exposes a standard Lustre client plus a CSI driver for AKS. Azure Files is the natural ReadWriteMany choice for cloud-native AI on AKS and Azure Container Apps. It tops out at 256 TB of capacity and 10.4 GB/s of throughput, offers LRS and ZRS redundancy with snapshots and soft delete, and ships with a 99.99% SLA. Azure Blob Storage sits underneath both of these as the cheap, durable core for data prep and long-term retention. The mental model the speakers used is “accelerator and core”. Blob is the core, durable and economical. AMLFS is the accelerator for training. Azure Files is the accelerator for inferencing and shared state. Pick the right pair for the stage you are running. How It Works, Under the Hood For training, Wolfgang showed the demo most folks came to see: a 32 x H100 ND H100 v5 AKS cluster deployed from the Azure AI Infrastructure repository, running a 30B-parameter GPT-3 training job backed by AMLFS. Two things matter here. First, AMLFS absorbs checkpoint write bursts. When 32 H100s flush state at the same time, you need a filesystem that can take the punch without stalling. AMLFS does, which keeps GPU utilization drops short and contained. Second, the AMLFS Lustre CSI driver for AKS supports both static and dynamic provisioning with availability-zone placement, and there are five SKU tiers from MLFS20 (cheapest by capacity) to MLFS500 (cheapest by bandwidth). That means you can pick a cost-performance point that matches your training budget instead of buying the top SKU and hoping for the best. For inferencing, Reena’s half of the session was just as practical. Five reasons Azure Files fits AKS ReadWriteMany workloads: Standard Kubernetes RWM volume over NFS or SMB. 256 TB capacity ceiling and up to 10.4 GB/s of throughput per share. LRS or ZRS redundancy with snapshots and soft delete for protection. 99.99% SLA so it shows up in your availability math. Native support across AKS and Azure Container Apps, including serverless GPU. The headline feature is Azure Files Provisioned v2. In the old model, IOPS and throughput were a function of how much capacity you provisioned, which is wrong for AI shapes that need small capacity but very high IOPS and bandwidth. Provisioned v2 splits capacity, IOPS, and throughput into three independent knobs you can dial without downtime or remount. That alone changes the economics for a lot of inferencing patterns. The other big inferencing feature is NFS v4.1 encryption in transit, delivered with the az-nfs utility and stunnel. You get AES-GCM TLS protection on the wire, with no Kerberos and no Active Directory needed, and the application has no idea it is happening. Reena’s live demo showed an AKS pod with an encrypted NFS mount, transparent to the workload. And then the pattern that ties it together: the shared model cache. Download the model once into Azure Files, mount it across every replica via ReadWriteMany. No per-pod cold start, no re-download from Hugging Face, no egress bill. The demo used GPT-OSS 120B with VLLM on 32 x H100, and the pattern scales down to small fine-tuned models running on serverless GPU in Azure Container Apps. Real-World Value The session closed with the Viton case study. Viton is a Paris-based fashion AI startup. Their image-generation platform runs on Azure Container Apps serverless GPU, with Azure Service Bus for job routing and Azure Files NFS as the shared model store. Workers pull jobs, mount the shared model cache, generate the image, and scale to zero when the queue drains. The economics only work because they are not paying to re-download the model on every cold start, and because they only pay for GPU when there is work to do. The same pattern shows up across customer scenarios: Training a foundation model on AKS with AMLFS as the scratch tier and Blob as the durable archive. Fine-tuning smaller models where AMLFS checkpoints absorb the write bursts and the final artifact lands back in Blob. Inferencing with VLLM on AKS where Azure Files holds the model weights once and every replica reads from the same RWM mount. Serverless inferencing on Azure Container Apps with the same shared model cache pattern, but with scale-to-zero economics. Honest tradeoff: Lustre is not the right filesystem for a 10-pod web app, and Azure Files is not the right filesystem for a 32-GPU training run. The whole point of the tiering is that you pick the right one per stage. Do not try to make one filesystem do all four jobs. Getting Started If you want to put this into practice this week: Go to the Azure AI Infrastructure repository on GitHub. Wolfgang’s demo cluster came straight out of it, and you can spin up an AI-ready AKS cluster with GPU and InfiniBand operators in your own dev/test subscription. Install the Azure Managed Lustre CSI driver on AKS if you are running training or fine-tuning. Start with a smaller MLFS SKU and size up. Turn on Azure Files Provisioned v2 on a new share, then dial capacity, IOPS, and throughput independently to match your inferencing shape. Enable NFS v4.1 encryption in transit with az-nfs and stunnel before you put any sensitive workload on the wire. Try the shared model cache pattern. Pick one VLLM deployment, point it at an Azure Files RWM mount, and measure cold start time before and after. Resources Azure Managed Lustre documentation Use the Azure Managed Lustre CSI driver with Azure Kubernetes Service Azure Files documentation Understand Azure Files billing (Provisioned v2) Encryption in transit for NFS Azure file shares Azure Container Apps serverless GPUs Azure AI Infrastructure repository on GitHub Keep Learning at the Summit Catch the full Microsoft Azure Infra Summit 2026 session playlist here Cheers! Pierre Roman
