Search
22 results for “filesystem”
Search results
Linux Filesystem Hierarchy & Permissions
Why /etc, /var, /usr, and /opt exist as separate, standardized directories under the Filesystem Hierarchy Standard, and how chmod's octal mode and umask actually decide a new file's permissions.
What is the Filesystem Hierarchy Standard, and why does it matter that /etc, /var, and /usr are separate directories rather than one flat structure?
The FHS is a specification for where files belong on a Unix-like system, so that any compliant distribution places configuration, variable data, and installed software in predictable locations regardless of vendor. Separating them matters operationally: /etc holds host-specific configuration that should be backed up and version-controlled, /var holds logs, caches, and other data that grows and changes constantly and often lives on its own disk or partition for capacity/IO reasons, and /usr holds installed programs and libraries that are typically read-only at runtime and can be shared or mounted the same way across many machines. Collapsing them into one flat structure would make it much harder to back up only what matters, mount storage with the right characteristics per use case, or reason about what's safe to wipe and reinstall.
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.
Linux Storage & Filesystems: Disks, Partitions, Mounts, and Disk Usage
How Linux Stores Data, Mounts Disks, and Survives Failures.
What do the three digits in a chmod octal mode like 644 or 755 actually mean, and what does a leading fourth digit add?
Each of the three digits is a sum of read (4), write (2), and execute (1), in order for the owner, the group, and everyone else; 644 means the owner gets read+write (4+2), while group and others get read-only (4). 755 means the owner gets read+write+execute (4+2+1), and group/others get read+execute (4+1), the common mode for an executable or a directory that others need to traverse. An optional leading fourth digit sets setuid (4), setgid (2), and the sticky bit (1); setuid/setgid make a program run with its owner's or group's privileges rather than the caller's, and the sticky bit on a directory (classically 1777 on /tmp) restricts file deletion to each file's own owner even though the directory itself is world-writable.
A process creates a file requesting mode 0666, but the file ends up with permissions 0644. What decided that, and would the outcome change if the parent directory had a default ACL?
The process's umask is what changed the requested mode: umask 022 turns off the write bit for group and others from any requested mode, so 0666 (rw-rw-rw-) becomes 0666 & ~022 = 0644 (rw-r--r--). The umask is applied by the kernel at file/directory creation time, not by the application deciding to be conservative. If the parent directory has a default ACL set, that changes the outcome: default ACL inheritance takes precedence over the umask entirely, so the new file's permissions would instead be derived from the ACL, not from applying umask to the requested mode.
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.
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.
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.
Linux Beginner Labs: Foundations (Understand Linux, Not Just Commands)
This lab helps you understand how Linux works internally, not just type commands. By the end of these labs, Linux will feel logical, not intimidating. Before You Start The Lab (Very Important). What You Need You can use any Linux environment : Ubuntu Desktop / Server Linux VM Cloud VM WSL (Windows…
Linux Foundations (Beginner): How Linux Really Works - Not Just Commands
Most beginners learn Linux backwards.
MongoDB can be configured to behave more like a CP system or more like an AP system. What settings make that choice, and what are they actually trading?
Write concern and read preference are the actual levers: a write concern requiring acknowledgment from a majority of replicas favors consistency, a write isn't considered successful until enough nodes agree, at the cost of availability if too many nodes are unreachable during a partition. A looser write concern, or reading from secondaries that might lag behind the primary, favors availability, operations keep succeeding even when full replica agreement isn't achievable, at the cost of potentially reading or acknowledging data that isn't fully consistent across the cluster yet. This is exactly the CP-versus-AP trade-off CAP describes, expressed as a concrete, tunable configuration rather than an abstract theorem.
How to Configure Secure File System Management with NTFS Permissions and Mapped Drives in a Windows Server Domain (Lab Guide)
This lab demonstrates how to design and implement secure file system management in a domain environment using Active Directory, Windows Server 2019, and Hyper V. The focus is on enterprise style file sharing, using NTFS permissions, group based access control, and mapped network drives, all aligned…
A banking system typically favors CP behavior during a partition, while a chat application typically favors AP. What does each system actually do differently when a partition occurs, and why does the choice fit each use case?
A CP system, during a partition, pauses or rejects requests that can't be guaranteed consistent, a bank stopping a transfer rather than risking two nodes independently approving withdrawals against the same balance, since a duplicated or lost transaction is a correctness failure worse than a temporary outage. An AP system keeps responding during the partition, accepting the risk of temporarily inconsistent state, a chat app still accepting and displaying messages on both sides of a network split, reconciling them once the partition heals, because staying available and eventually consistent matters more to users than every message reappearing everywhere in a strict, immediate order.
What does it mean for a sorting algorithm to be "stable," and why does that matter for sorting by multiple keys in separate passes?
A stable sort guarantees that when two elements compare as equal under the current sort key, their original relative order is preserved rather than left unspecified. This matters directly for multi-key sorting done as a series of single-key sorts: sort by a secondary key first, then stably sort by the primary key, and elements sharing the same primary key retain their secondary-key order from the first pass, correctly producing a combined sort by (primary, secondary) without needing a single comparator that handles both keys at once. An unstable sort would silently scramble that secondary ordering among equal-primary-key elements.
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.
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.
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 a Docker image and a Docker container?
An image is a read-only, layered filesystem snapshot plus metadata (entrypoint, exposed ports, environment); it never changes once built and can be shared through a registry. A container is a running (or stopped) instance of an image: Docker adds a thin writable layer on top of the image's read-only layers and starts a process inside an isolated namespace. You can start many independent containers from the same image, each with its own writable layer and state, the same way many processes can run from the same binary on a normal OS.
What is the difference between the Baseline and Restricted Pod Security Standards levels, and why are they cumulative?
Baseline blocks the most well-known container privilege-escalation paths, privileged containers, host namespaces, hostPath volumes, dangerous Linux capabilities, while still allowing a fairly permissive pod spec otherwise. Restricted inherits every Baseline rule and adds real hardening on top: it requires running as non-root, forbids privilege escalation outright, requires a restricted seccomp profile, and requires dropping all Linux capabilities except NET_BIND_SERVICE. A read-only root filesystem is not part of either standard, it's a separate hardening measure some organizations layer on as their own policy, on top of, not as part of, Restricted. They're cumulative by design, Restricted is Baseline plus more, so a workload that passes Restricted automatically satisfies Baseline too, and a cluster can apply different levels per namespace based on how much a given workload can be trusted.
Linux Engineer Roadmap
From the filesystem hierarchy and permissions through users, networking, process management, storage, and logging, the core path for a working Linux engineer, linked into Cloud Tech by Victor topic references.
Why does using a monotonically increasing field (a sequential ID, a timestamp) as a shard key concentrate all new writes onto one shard, even with range-based sharding across many shards?
With range-based sharding, chunks are assigned contiguous ranges of shard-key values, and a monotonically increasing key means every new document's value is higher than every previously inserted one, so all new inserts land in whatever chunk currently owns the highest range, which lives on one specific shard. Every other shard, holding older, lower-valued ranges, receives none of the new write traffic at all, the exact "hot shard" problem, all insert load concentrated on a single shard regardless of how many total shards the cluster has.