Search
30 results for “storage”
Search results
AWS Storage
How S3, EBS, and EFS fit different access patterns, what S3 storage classes actually trade off, and why durability and availability are two different numbers.
Azure Storage
How Blob, File, and Disk storage in Azure fit different access patterns, what redundancy options (LRS, ZRS, GRS) actually protect against, and why access tiers change cost, not durability.
Linux Storage & LVM
How physical volumes, volume groups, and logical volumes let LVM pool multiple disks and resize storage without repartitioning, and what mount and /etc/fstab actually do to attach a filesystem to the directory tree.
What is the difference between durability and availability in S3, and why does it matter when picking a storage class?
Durability is the probability that a stored object is not lost over a year, and S3 Standard, Standard-IA, and every Glacier class are all designed for the same 99.999999999% (11 nines) durability. Availability is how often the object can actually be successfully retrieved on demand, and that number does vary by class, 99.99% for Standard down to 99.5% for One Zone-IA. It matters because a cheaper class is not automatically a less durable one, S3 One Zone-IA is exactly as durable as Standard-IA per object, but it is not resilient to the loss of its single Availability Zone at all, since it isn't replicated across multiple zones the way every multi-AZ class is.
What is the difference between Blob Storage, File Storage, and Disk Storage in Azure?
Blob Storage is object storage for unstructured data (images, backups, logs), accessed via HTTP/HTTPS APIs, not mounted as a filesystem. File Storage provides fully managed file shares accessible via the SMB or NFS protocol, usable as a network drive that multiple VMs can mount simultaneously. Disk Storage provides block-level storage attached to a single VM, functioning as its virtual hard disk. The choice depends on access pattern: Blob for API-driven unstructured data at scale, File for shared network-drive-style access across machines, Disk for a VM's own persistent local-feeling storage.
What is the difference between locally redundant storage (LRS), zone-redundant storage (ZRS), and geo-redundant storage (GRS)?
LRS replicates data three times within a single datacenter; it protects against hardware failure but not a datacenter-level outage. ZRS replicates synchronously across three availability zones within one region, protecting against a single datacenter failure while keeping data within the region. GRS replicates asynchronously to a second, geographically distant region on top of LRS in the primary region, protecting against a regional disaster at the cost of the secondary copy lagging slightly behind (eventual, not synchronous, consistency) and being unreadable by default unless read access is explicitly enabled (RA-GRS).
How do access tiers (Hot, Cool, Archive) affect Blob Storage, and what do they not affect?
Access tiers change the cost trade-off between storage price and access/retrieval price: Hot has the highest storage cost but cheapest, immediate access; Cool has lower storage cost but a higher per-access cost and is meant for infrequently accessed data; Archive has the lowest storage cost but data must be rehydrated (a process taking hours) before it can be read at all. What tiers do not affect is durability, the redundancy option (LRS/ZRS/GRS) determines durability independently of which access tier a blob is in, so a Cool or Archive blob is exactly as durable as a Hot one with the same redundancy setting.
What is the difference between journald's "volatile", "persistent", and "auto" storage modes, and which one is the default?
"Volatile" keeps the journal only in `/run/log/journal`, which is memory-backed and wiped on every reboot, nothing survives a restart. "Persistent" writes to `/var/log/journal` on disk, so entries survive reboots (falling back to volatile only during very early boot or if the disk is unavailable). "Auto" is the actual default, and it behaves like "persistent" only if `/var/log/journal` already exists, otherwise it behaves like "volatile", so whether logs survive a reboot on a given system depends entirely on whether that directory happens to have been created, not on any setting an administrator consciously chose.
Linux Storage & Filesystems: Disks, Partitions, Mounts, and Disk Usage
How Linux Stores Data, Mounts Disks, and Survives Failures.
Securing Azure Blob Storage with PowerShell: Network Isolation, SAS Access & Immutable Policies (Beginner to Pro)
A hands-on lab automating secure Azure Blob Storage using VNets, subnets, SAS tokens, and immutability.
Hands-On Lab: Scalable Hyper-V Storage with iSCSI, VHDs & Storage Pools
Virtual Disks, Storage Pools, and iSCSI - The Hidden Challenges of Hyper-V Storage (And How I Solved Them)
How to Restrict USB and Removable Storage Devices using Group Policy in Active Directory
This lab documents a real world Group Policy implementation used to restrict USB drives, external hard drives, and all removable storage devices across domain joined systems in an Active Directory environment. The configuration addresses a critical security risk in modern on premises and hybrid env…
What is the difference between S3, EBS, and EFS?
S3 is object storage accessed entirely through an HTTP(S) API, not mounted as a filesystem, built for unstructured data at virtually unlimited scale. EBS is block storage that attaches to exactly one EC2 instance at a time (Multi-Attach for io1/io2 is the narrow exception) and must live in the same Availability Zone as that instance, functioning as its persistent virtual hard disk. EFS is a fully managed NFS file system that is regional by default, replicated across multiple Availability Zones, and can be mounted concurrently by many instances at once. The choice comes down to access pattern: S3 for API-driven object access, EBS for a single instance's own low-latency block storage, EFS for a shared network file system across many instances.
Why would you use EFS instead of EBS for a given workload?
EBS attaches to a single EC2 instance and lives in one Availability Zone, which is exactly right for a database's own local-feeling disk but doesn't work at all when more than one instance needs to read and write the same files concurrently. EFS is designed for exactly that case: a regional, NFS-mountable file system that many EC2, ECS, or Lambda-backed clients can mount and use at the same time, with strong consistency across them. The trigger for reaching for EFS instead of EBS is almost always "does more than one compute resource need to share this data," not a performance decision alone.
How do a physical volume, a volume group, and a logical volume relate to each other in LVM?
A physical volume (PV) is an actual disk or partition brought under LVM's management. A volume group (VG) pools one or more physical volumes into a single unit of storage capacity, the VG's total size is the combined size of every PV in it. A logical volume (LV) is a virtual block device carved out of a VG's available space, and the Device Mapper layer in the kernel is what actually maps each block of an LV to blocks on one or more of the VG's underlying PVs. This is what makes LVM flexible in a way a plain partition isn't: an LV can be resized, or a VG can absorb another disk as a new PV, without the rigid, fixed boundaries a traditional partition table imposes.
Why would you add a second disk to an existing volume group instead of just creating a new, separate filesystem on it?
Adding a disk as a new physical volume to an existing volume group extends that VG's total capacity, which lets an existing logical volume (and the filesystem on it) be grown into the new space without unmounting it, moving data, or changing the mount point the rest of the system already depends on. Creating a second, separate filesystem on the new disk instead means the original filesystem is still capacity-constrained by its original disk, and anything needing more room has to be manually split or migrated across two independent mount points rather than one that simply grew.
What is the difference between running "mount" once from the command line and adding an entry to /etc/fstab?
A manual `mount` command attaches a filesystem to the directory tree for the current running session only, it does not survive a reboot, the system has no record of it having ever happened. An `/etc/fstab` entry is the persistent, declarative definition of what should be mounted where and with what options, and it's what the boot process (and `mount -a`) reads to reconstruct every expected mount automatically. A filesystem mounted manually but never added to fstab is the classic cause of "it worked, then disappeared after a reboot," and works precisely because it was set up as a one-time action, not a declared, persistent one.
How to Configure Azure File Sync
For many years, organizations have relied on traditional methods of sharing files, most commonly through mapped network drives connected to on‑premises Windows servers. This approach has served businesses well, especially those with domain‑joined computers and centralized IT infrastructure. However…
Build a Secure Azure Environment in Minutes with Bicep: VMs, Networking, Private Endpoints & Blob Replication
A hands-on Infrastructure-as-Code lab deploying a production-ready Azure environment from a single Bicep template.
Embeddings & Vector Search
How embeddings turn text into vectors that cosine similarity can compare mathematically, why shortening an embedding's dimensions trades some accuracy for real storage and speed savings, and when semantic search actually beats keyword search.
Linux Fundamentals
The core command-line building blocks - navigation, permissions, processes, networking, and services - that every other Linux topic on this site (filesystem hierarchy, storage, users, networking) assumes you already have.
Linux Logging & Monitoring with journald
Why journald's default "auto" storage mode can quietly discard logs across a reboot on a fresh system, and how journalctl's unit and priority filters actually narrow down a live incident.
Linux Users, Groups & sudo
How /etc/passwd and /etc/shadow split identity from password storage, why a UID (not a username) is what the kernel actually checks, and how a sudoers rule's who/where/as-whom/what structure grants privileges.
What is the difference between Azure RBAC and Entra ID roles?
Entra ID roles (like Global Administrator, User Administrator) control access to Entra ID and Microsoft 365 management functions themselves, managing users, groups, and directory settings. Azure RBAC controls access to Azure resources (VMs, storage accounts, resource groups) via role assignments scoped to a management group, subscription, resource group, or individual resource. They are separate systems that both use Entra ID as the identity provider, a user authenticates once through Entra ID, but what they can then do is governed by two independent role systems depending on whether they're managing identity itself or managing Azure resources.
How do Azure Monitor, Log Analytics, and Application Insights relate to each other?
Azure Monitor is the umbrella platform for all monitoring data in Azure, metrics, logs, and alerts across every resource. Log Analytics is the query and storage engine underneath it that holds log data in workspaces and is queried using KQL (Kusto Query Language). Application Insights is Azure Monitor's application-performance-monitoring feature specifically, which auto-instruments application code to collect request traces, dependency calls, and exceptions, and stores that data in a Log Analytics workspace like everything else. They are not three separate products so much as one platform (Azure Monitor) with a query engine (Log Analytics) and an application-specific instrumentation layer (Application Insights) on top of it.
What are the five stages of the browser rendering pipeline, and which ones does a change to a property like width actually have to go through?
The pipeline runs JavaScript, Style calculation, Layout, Paint, and Composite, in that order. Changing a property that affects geometry, `width`, `height`, `position`, forces the browser through every stage: layout has to be recalculated (since the element's size or position changed), then paint (since pixels changed), then composite. That full path is why layout-affecting properties are the most expensive to animate, every frame re-runs the whole pipeline, not just a cheap final step.
What is the actual difference between IaaS, PaaS, and SaaS?
The difference is the boundary of what the provider manages versus what you manage, not the technology itself. IaaS (e.g., a raw virtual machine) gives you compute, storage, and networking; you manage the OS, runtime, and application. PaaS (e.g., a managed application platform) additionally manages the OS and runtime, so you only manage your application code and configuration. SaaS (e.g., a hosted email or CRM product) manages everything, including the application itself; you're just a user or configurer of it. Moving up the stack trades control for reduced operational burden.
What is a shard key, and why does a low-cardinality shard key (few distinct values) cause a hot shard?
A shard key is the field (or fields) a sharded database uses to decide which shard each document or row actually lives on. If that field has few distinct values, say `country`, and the real data is skewed (80% of users in one country), the vast majority of documents route to the same shard regardless of how many shards exist in the cluster, overwhelming it with disproportionate read/write load and storage while other shards sit comparatively idle. Cardinality alone doesn't guarantee even distribution either, the values also need to actually occur with reasonably even frequency in the real data, not just theoretically have many possible values.
What does "overlapping subproblems" mean, and why does dynamic programming provide no benefit for a problem that lacks it?
Overlapping subproblems means the same smaller subproblem genuinely recurs multiple times across different branches of the larger problem's recursive structure, exactly what makes caching valuable, the second and later occurrences become free lookups. A problem like standard mergesort, by contrast, has no overlapping subproblems, every recursive call operates on a genuinely distinct slice of the array that never recurs anywhere else, so there is nothing to cache and memoization adds only overhead (cache storage and lookup cost) with zero reuse to offset it. Recognizing whether a problem's recursive breakdown actually revisits the same subproblems is the real prerequisite for dynamic programming to help at all.
Why would you shorten an embedding from 1536 dimensions to 256, and what do you give up by doing it?
Fewer dimensions means less storage per vector and faster similarity computation at query time, which matters directly at scale, a vector database holding millions of embeddings pays that storage and compute cost on every one of them. Modern embedding models are specifically trained to support this trade-off gracefully: a newer model shortened to 256 dimensions can still outperform an older, unshortened model at 1536 dimensions, so shortening isn't simply "less accurate," it's a deliberate trade against a specific model's own accuracy ceiling. What you give up is some of that ceiling, the shortened embedding is measurably less precise than the same model's full-length embedding, which is why the right dimension count depends on how much accuracy a specific use case can actually trade away.