Video summary

ТОП 10 ВОПРОСОВ НА СОБЕСЕДОВАНИИ ПО LINUX

Main summary

Key takeaways

Technology

Summary of the video (Top 10 Linux interview questions for DevOps)

The channel ProstopS presents and explains common Linux/DevOps interview questions, focusing on internals and practical diagnostics. The “answers” are structured like mini-guides.

1) Difference between hard links and symbolic links (symlinks)

Hard link

  • A hard link is another directory entry pointing to the same inode (i.e., the same underlying file data).
  • Creating a hard link:
    • adds a new entry in a directory
    • increments the inode’s hard link/reference counter
  • Deleting a hard-linked name:
    • removes the directory entry
    • decrements the counter
    • disk data is removed only when link count becomes 0 and no process has the file open
  • Limits:
    • cannot cross filesystem boundaries (inode numbers are local per filesystem)
    • cannot link directories (to avoid infinite loops during traversal)

Symlink

  • A symlink is a separate file with its own inode/number.
  • Its content is a path string to the target.
  • “Fast symlink” optimization:
    • if the path is short (≤ ~60 bytes), the path is stored directly in the inode’s i_block area
    • otherwise it stores the path in an allocated data block
  • Access behavior:
    • the kernel reads the stored path and resolves it
    • if symlinks point to symlinks, resolution follows a chain with a limit (~40 hops), otherwise an error occurs
  • Permission nuance:
    • symlink permissions are effectively ignored; access is determined by the target file’s permissions
  • Broken behavior:
    • if the target is deleted, the symlink becomes “broken”
    • if a new file is created later at the same path, the symlink works again (because it stores the path, not an inode reference)

Practical uses mentioned

  • Hard links in incremental backups/snapshots (e.g., rsync/snapshot-like behavior where unchanged files are hard-linked to save space).
  • Symlinks for configuration management, e.g.:
    • sites-enabled / sites-available patterns (web servers like Nginx)
    • inclusion of system unit configs
    • library version chains
    • common symlink structure like /usr/bin

2) Meaning of 755 for directories, especially what execute means

  • Usual mapping:
    • owner rwx (7)
    • group r-x (5)
    • others r-x (5)

Key interview depth: what does x mean on a directory?

  • Directory permissions govern access to the directory’s internal mapping (entries → inode metadata).
  • Read (r):
    • allows listing names (e.g., ls shows entries)
  • Execute/Search (x):
    • allows traversal (enter the directory)
    • enables inode lookups by name (needed for commands like ls -l, because metadata requires inode access)

Path traversal requires execute everywhere

  • To access /home/user/file, the kernel checks x on:
    • root, home, user, etc.

Write (w) on directories

  • Allows creating/deleting/renaming entries.
  • Typically depends on x being present.

Special bits

  • Sticky bit (e.g., /tmp with 1777):
    • restricts deletion: only the file owner, directory owner, or root can delete
  • Setgid bit on directories:
    • newly created items inherit the directory group (and works recursively through subdirectories)

3) free command: what it shows and how buffer/cache and available work

free

  • Interprets memory lines such as:
    • total
    • free
    • used (and related fields)
    • buff/cache (combined cache)
  • The video emphasizes a common confusion:
    • “Free” memory can look low, because Linux uses free memory as cache efficiently.

available

  • Explained as a healthier metric:
    • how much memory can be used without swapping
  • Linux frees cache aggressively:
    • clean page cache can be dropped quickly
    • some reclaimable memory is also considered
  • available is computed using reclaimable portions (the presenter mentions approximations like “about half” for certain caches).

buff/cache decomposition

  • buff/cache = buffers + page cache + reclaimable
  • Conceptually:
    • page cache: cached file contents
      • clean pages (match disk)
      • dirty pages (must be flushed first)
    • buffer cache: filesystem metadata structures (e.g., superblock, descriptors)
  • Takeaway:
    • high buff/cache (e.g., 13GB) is usually not “bad” if available is high.

Memory allocation internals (lazy allocation)

  • Linux uses lazy allocation:
    • requesting memory doesn’t allocate physical pages immediately
    • physical pages appear on first write via a page fault (“page-in” concept)

4) What is LVM and why it’s needed (growth + snapshots)

Goal/problem

  • Expand a nearly full partition (e.g., /var on a separate partition) without:
    • copying data
    • reformatting
    • editing fstab
    • rebooting

LVM concept

  • LVM (Logical Volume Manager) is a layer between physical storage and filesystems.
  • Three levels:
    1. PV (Physical Volume): disk/partition initialized for LVM
      • LVM writes metadata and splits remaining space into extents
      • default extent size mentioned: PE ~4MB
    2. VG (Volume Group): pool combining one or more PVs
      • PE size consistent within a VG
      • metadata duplication across PVs for resilience
    3. LV (Logical Volume): virtual block device presented to the filesystem
      • appears as a normal block device to the OS/apps

Dynamic expansion scenario

  • The presenter describes expansion as a small sequence of steps:
    • initialize new PV / add to VG
    • expand LV
    • expand filesystem (online)
  • Mentioned: ext4 and xfs support online expansion.

Snapshots

  • Snapshot creation:
    • not a full copy
    • allocates a separate area for changed blocks
    • uses copy-on-write behavior:
      • on first write after snapshot, old data is saved elsewhere first
  • Downsides:
    • first write after snapshot causes extra I/O (read old + save + write new)
    • multiple snapshots multiply overhead
    • snapshot storage is fixed-size; if full, snapshot may be removed and changes can be lost
  • Mentioned strategy:
    • auto-expansion to grow when usage reaches a threshold (e.g., ~70%)

Related principle

  • Similar to “thin” behavior: logical allocation may not equal immediate physical consumption—monitor pool capacity.

Tie-in

  • The mapping resembles kernel virtual block device mapping ideas; the presenter also notes Docker overlay uses similar mapping infrastructure.

5) strace: what it shows and when to use it

  • Strace intercepts every system call from a process and shows:
    • system call name
    • arguments
    • return value
  • Uses a tracing control concept similar to ptrace:
    • process is paused on syscall entry and syscall exit to collect info
  • Performance impact:
    • can slow down apps that make many syscalls

When to use it

  1. App won’t start and logs are empty/unclear:
    • run strace to see which files/syscalls succeed or fail
  2. Process appears frozen:
    • attach to the live process and identify the syscall it’s stuck on

6) File descriptors: what they are and limits

  • A file descriptor is a number assigned by the kernel when a process opens something.
    • example given: descriptor 3
  • Standard descriptors at process start:
    • 0 stdin, 1 stdout, 2 stderr
    • then 3 onward for other opens
  • Kernel internals:
    • each process has a descriptor table (indexed by FD)
    • FD points to kernel structures holding open state (offset, flags, reference counts)
    • those reference file objects/inodes/devices/sockets

Limits

  • per-process soft limit (often ~1024 in practice; presenter mentions varying figures including the soft/hard limit concept)
  • soft vs hard limits:
    • process can raise soft up to hard

Real-world symptom

  • “too many open files”:
    • inability to accept new connections
    • example: many TCP connections exhaust descriptors

7) “Disk full” discrepancy between df and du

Issue

  • df shows filesystem near full, but du on directories shows much less.

Explanation

  • df measures block usage at filesystem level, not directory-tree reachability.
  • du counts what’s reachable from a directory tree (depends on directory entries).

Common cause: deleted but still open files

  • If a process still holds an open FD for a deleted file:
    • blocks remain allocated
    • directory entry disappears, so du ignores it
    • df still shows the space as used

8) “No space left on device” even when there is free space

Main cause: inodes exhausted

  • Blocks may be free, but the filesystem can’t create new files because it has no remaining inode entries.

Diagnostic

  • use tools like df -i to check inode usage (contrast with df, which checks blocks).

When it happens

  • many small files, e.g.:
    • mail server messages stored as individual files
    • cache directories with millions of tiny files

Filesystem differences (as described)

  • XFS:
    • allocates inodes dynamically, making inode exhaustion less likely
  • btrfs:
    • described as mitigating by sharing resources (presenter states i-nodes and blocks are effectively combined)

Other cause

  • filesystem errors causing the kernel to remount filesystem read-only
    • check kernel logs for filesystem errors and remount events

9) High I/O wait/load with low CPU load: what are EOT/EOW?

  • The presenter defines behavior like I/O wait idle:
    • CPU appears “idle/free” while processes are blocked waiting for I/O
  • Why load can be high:
    • “load” reflects tasks waiting/runnable, not just CPU usage
    • if many processes wait for a slow disk, load average rises while CPU remains low.
  • Likely causes mentioned:
    1. slow disk
    2. swap activity
      • disk-backed paging slows everything; processes block on swap reads
    3. application uses lots of disk-resident working data not fitting in RAM (e.g., database working set)

10) Final question only partially shown

  • The video ends with a teaser-like “10th question” referencing a case like load average values (e.g., “504”) with low load age, but the details aren’t included.
  • It suggests viewers check the analysis in Telegram/comments.

Main speakers/sources

  • Speaker/source: The channel ProstopS.
  • Additional references/tools mentioned: ln-style concepts, ls, free, LVM, strace, df/du, inode concepts, swap, CPU/I/O metrics, and filesystem types like ext4 and XFS.

Original video