Linux
Table of Contents
- Linux Performance Tools
- Inode Structure
- NUMA(Non-uniform memory access)
mkswap
- Config swap spaces/files
lsblk
mkfs
/etc/fstab
- Mount a Volume
- Links
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]$ dd if=/dev/zero of=/swap_file bs=1024k count=num_mb
[root]$ mkswap /swap_file
[root]$ swapon /swap_file
lsblk
reference
mkfs
reference
/etc/fstab
reference
Mount a Volume howto
# view your available disk devices and their mount points
[root]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
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
# 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
lost+found
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, calledlost+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 forfsck
to deposit files there. (…) If you accidentally deletelost+found
, don't re-create it withmkdir
, usemklost+found
if available.