Table of Contents

Linux Performance Tools reference

Inode Structure discussion

inodes starts at number 2 (root)

inode12(dir1)’s count is 2, because it’s parent and self-reference(.) pointing it. root(2) is only exception(expected 3 but 4), because it’s pointed by superblock;

The superblock is essentially file system metadata and defines the file system type, size, status, and information about other metadata structures (metadata of metadata).

$ ls -i
624402 Applications   638157 Dropbox        606644 Pictures     19695291 nltk_data
606600 Desktop        606588 Library      19316918 PredictionIO  2688212 repos
606584 Documents      606640 Movies         606646 Public       24277126 screenshots
606586 Downloads      606642 Music        24707402 bin          22461472 venvs
$ touch test
$ stat test
File: 'test'
Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: ca01h/51713d    Inode: 14999       Links: 1
Access: (0664/-rw-rw-r--)  Uid: (  500/ec2-user)   Gid: (  500/ec2-user)
Access: 2017-03-02 18:20:00.503961613 +0000
Modify: 2017-03-02 18:20:00.503961613 +0000
Change: 2017-03-02 18:20:00.503961613 +0000
Birth: -

NUMA(Non-uniform memory access) discussion

A system can starve several processors at the same time, notably because only one processor can access the computer's memory at a time.(…) NUMA attempts to address this problem by providing separate memory for each processor, avoiding the performance hit when several processors attempt to address the same memory.

mkswap reference

Config swap spaces/files howto

[root]$ mkswap /dev/hdb1
[root]$ swapon /dev/hdb1
[root]$ dd if=/dev/zero of=/swap_file bs=1024k count=num_mb
[root]$ mkswap /swap_file
[root]$ swapon /swap_file
[root]$ swapoff -a  # turns off all swap spaces
[root]$ rm -f /swap_file

lsblk reference

mkfs reference

/etc/fstab reference

Mount a Volume howto

# view your available disk devices and their mount points
[root]$ lsblk
xvdf  202:80   0  100G  0 disk
xvda1 202:1    0    8G  0 disk /

# check other details
[root]$ blkid
/dev/xvda1: LABEL="/" UUID="abcdefgh-1234-ijkl-4567-qwertyasdfgh" TYPE="ext4" PARTLABEL="Linux" PARTUUID="12321555-asda-asas-asdg-142khkhkhcsd"
[root]$ file -s /dev/xvda1
/dev/xvda1: Linux rev 1.0 ext4 filesystem data, UUID=1701d228-e1bd-4094-a14c-8c64d6819362, ...

[root]$ file -s /dev/xvdf
/dev/xvdf: data  # no file system
[root]$ mkfs -t ext4 /dev/xvdf
[root]$ mkdir /my/path
[root]$ mount /dev/xvdf /my/path
# Mount the volume permanently
[root]$ cp /etc/fstab /etc/fstab.orig  # backup

# /etc/fstab : columns are separated with ' ' or '\t'
# ------------------------------------------------------------------------------
# Use UUID because /dev/xvdf may change
# - check UUID from the output of file -s /dev/xvdf
# SEE: $ man fstab
# - 0 stands for (not dumping, default)
# - 2 stands for (other than root volume)
/dev/xvda1  (...)
UUID=de9a1ccd-a2dd-44f1-8be8-2d4275cb85a3  /my/path  ext4  defaults,nofail  0  2
# ------------------------------------------------------------------------------

# mount with /etc/fstab manually
[root]$ mount -a


The thing is, the file had a name and location once, but that information is no longer available. So fsck deposits the file in a specific directory, called lost+found

Files that appear in lost+found are typically files that were already unlinked (i.e. their name had been erased) but still opened by some process (so the data wasn't erased yet)when the system halted suddenly (kernel panic or power failure). If that's all that happened, these files were slated for deletion anyway, you don't need to care about them.

On many filesystems, the lost+found directory is a bit special because it preallocates a bit of space for fsck to deposit files there. (…) If you accidentally delete lost+found, don't re-create it with mkdir, use mklost+found if available.