sparcs wheel seminar @night file system, physical disk

100
File System, Physical Disk SPARCS Wheel Seminar @Night

Upload: others

Post on 18-Dec-2021

3 views

Category:

Documents


0 download

TRANSCRIPT

File System, Physical DiskSPARCS Wheel Seminar @Night

Booting

1. Booting

부팅 과정의 간략한 소개

BIOS (or UEFI) → Boot Loader → Kernel → Init (User Space Configuration) → Login Prompt (User Shell)

1. Booting

User presses the power button (IBM x86 기준)

A. 메인보드에 파워가 들어옴

B. CPU 에서 Real Mode (실제 물리 주소) 로 FFFF FFF0 JMP (ROM BIOS Entry)

C. BIOS (또는 UEFI) 로 컨트롤을 넘김

1. Booting

BIOS

- Basic Input Output System- 메인보드 회사에서 업데이트를 제공할 수 있게 EPROM

(Erasable Programmable Read Only Memory) 에 저장- 구형 펌웨어- 보통 부팅은 MBR으로 진행 (사전에 정해둔 설정에 따라

MBR이 포함된 Bootable Media가 발견될 때 까지 탐색)

UEFI- Unified Extensible Firmware Interface- 좀 화려하다 싶으면 보통 UEFI- efibootmgr 명령어로 linux에서 부팅설정 관리 가능- GPT, MBR 을 이용하여 부팅 가능- Secure Boot를 지원 (따라서 인증서 없는 드라이버는 실행X)

1. Booting

MBR- Master Boot Record- 대부분의 OS 와 하드웨어에서 지원함- 하나의 하드에서 4개의 파티션 까지 지원함. (C, D, … )- 그런데 마지막은 Extended Partition으로 설정하여 파티션 추가 가능

(Pointer 느낌..?)- 여러 기능을 지원하지만 한 파티션에서 2TB 까지만 이용 가능- 최대 446바이트의 부트 코드를 지원함 (여기에 넣을 수 있는 것은

부트로더로의 JMP…)

GPT

- GUID Partition Table - 128개의 파티션 지원, 마찬가지로 확장 가능- 제타바이트 (..!) 의 하드 디스크 지원 (사실상 무제한)- 64-bit 하드웨어나 64-bit 소프트웨어 요구- 64-bit가 아니어도 데이터 드라이브로 GPT 이용 가능- ESP (EFI System Partition 지원)

1. Booting

BIOS (UEFI)로 컨트롤이 넘어옴

A. POST (Power On Self Test)로 메인보드에 연결된 여러 기기 확인

이 과정에서 메인 메모리 (DRAM), PCI/PCIe 버스 및 기기들 확인 (위잉하고 돌아간다..!) 오류 발생하면 주로 비프음 발생

B. Non-Volatile Storage Devices를 순차적으로 탐색하면서 MBR(GPT) 발견

C. BIOS (UEFI) 에서 Partition Table (MBR/GPT) 를 메모리로 로드

D. 가장 첫 번째 파티션에 있는 Boot Sector Code 실행

1. Booting

MBR

- MBR의 Boot Sector Code에는 거의 Bootloader (GRUB) 등으로 JMP 하는 코드…- (물론 여기에다 게임을 넣는 사람들도 있다)

GPT / ESP (EFI System Partition)

- ESP 는 GPT 에서 GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B- 파티션 중 하나지만 부팅에 사용됨 (/boot, /boot/efi, /efi 등에 마운트)- 최소 32MiB, (권장 100MiB) 로 할당- (/boot에 마운트할 경우, 업데이트 과정에서 부트 이미지가 채워지기 때문에 그 이상 할당 가능)- 부트로더 (*.efi 파일) 들이 이 공간에 상주- GRUB 를 사용하는 경우, grub.efi를 로드하여 GRUB 시작. Systemd-boot (Gummiboot)를

사용하는 경우, 여기에서 바로 Kernel 실행 가능

1. Booting

GRUB (grub.efi) 실행

- Grand Unified Bootloader (약자가 억지스럽다)- 모든 하드 디스크에서 OS를 찾고, 리눅스나 기타 OS 실행을 보조하기 위한 부트로더. - 기능이 많아서 OS를 실행하기 위한 OS 느낌이다

설정 파일 위치

- /etc/default/grub (grub-mkconfig로 자동생성)- /etc/grub.d/- /boot/grub/grub.cfg

GRUB이 안뜨고 바로 리눅스로 넘어가는 경우, Shift를 눌러 GRUB를 뜨게 할 수 있다.

$ sudo –s$ grub-mkconfig –o ~/grub.config$ cat ~/grub.config

1. Booting

부트로더가 커널 (Linux)를 시작

- /boot/vmlinuz… (z는 압축, x는 미압축)- 압축되어 있으면 우선 압축을 해제함- 커널은 컴퓨터의 메모리와 연결된 하드웨어 관리를 시작함. (CPU, I/O, 저장장치 등)- 지정된 메모리 위치에 있는 압축된 initrd 이미지 탐색, 압축 해제 및 마운트

1. Booting

initrd Image (initramfs)

- 커널 로드 전에 시작하는 RAM 기반 파일 시스템- RAM 내부에 임시적인 파일 시스템을 생성함- 왜 이런 것이 필요하냐면 네트워크 부팅의 경우, 네트워크 드라이버가 있어야 커널 로드 가능- 근데 네트워크 드라이버는 커널이 시작되야 사용 가능 (..!)- 따라서 initrd 이미지를 (initial ram disk or initial rood disk) 를 먼저 RAM 에 로딩한 다음,

이를 디스크 처럼 인식하여 커널 시작에 필요한 스크립트를 돌림. 커널이 시작된 다음 루트파일 시스템으로 전환하여 init 프로세스 전환.

1. Booting

부트로더가 커널 (Linux)를 시작

- 가상 기기들 (LVM, RAID 등) 동작 후 initrd 언마운트- Root device 생성 후 마운트 (여기부터 커널이 완벽히 동작 중!)- 이제 사용자 환경 구성을 위해 /sbin/init 커맨드 실행! (linuxrc) 처음 시작되는 프로세스

$ ps -p 1$ ps –ef | grep init

- (최근에는 init 프로세스 대신 systemd 를 이용, symlink 사용)- 현재 Runlevel에 맞는 프로그램을 실행

$ cd /etc/$ ls –al | grep rc

- (참고) systemctl restart mongodb 와 같은 커맨드는 systemd에 명령을 내리는 것이다!

1. Booting

Runlevel

- 0 = halt- 1 = Single User Mode- 2 = Multiuser, w/o NFS- 3 = Full Multiuser- 4 = Unused- 5 = X11- 6 = Reboot

- S는 Startup, K 는 Kill (Shutdown)- 뒤의 번호는 프로그램의 실행 (시작 또는 종료) 순서를 뜻함

File System

2. File System

What is File System?

- 파일 시스템 (fs)는 데이터의 저장과 접근을 관리하는 방식- Fs가 없다면 하드 디스크에 거대한 데이터 덩어리가 있고, 각 파일이 어디서 어디까지 있는지,

어떻게 해독할 수 있는지를 알 수 없을 것!

Linux Storage Devices

$ ls –al /dev | grep “^b” 또는 $ lsblk

- 여기에서 ‘b’는 block special file (섹터 단위로 엑세스 할 수 있는 디바이스)를 뜻함

( ‘-’ : regular file, ‘c’: character special file, ‘C’ : high performance, ‘d’: directory, ‘l’: symlink)

- SATA 드라이브는 /dev/sda , /dev/sdb … , IDE (병렬) /dev/hda , ..- 파티션은 /dev/sda1, /dev/sda2 … 로 나누어서 관리

2. File System

What is File System?

- 리눅스에서 파일 시스템 상태를 확인하기 위해서는 df 커맨드를 이용한다.

$ df [-h] # -h 는 human-readable로 M, K등 인간이 읽기 쉬운 단위로 출력해 준다.

2. File System

리눅스와 윈도우가 다른 점

- 윈도우: USB를 꽂으면 NT 커널이 알아서 새 드라이브 레터를 매핑해 연결해줌- 리눅스: 그런 daemon 을 만들 수 있지만 (systemd.mount unit file을 만드는 등) 디폴트는

수동

실습 (가능하신 분들) USB를 마운트해 보자!

$ mount –t [fs type] [device file] [mount location]

$ mount –t ext4 /dev/sdb1 /mnt/shared

- 파일시스템 타입을 모르면 –a

$ mount

$ cat /etc/mtab

2. File System

USB 언마운트

$ umount [device file] or [mounted directory]

$ umount /dev/sda1

- 어떤 프로세스가 해당 디렉터리 (디바이스)를 이용중이라면 언마운트 불가 (busy)- Cd 등으로 wd가 해당 디렉터리인 경우도 포함

$ cat /etc/fstab

재부팅 다음 자동으로 mount 하기 위해서는 /etc/fstab 을 편집하면 된다.

/dev/sdb1 /mnt/shared ext4 defaults 1 2

[Device] [Mount Point] [File System] [Mount Options] [Dump] [Check File system]

Root가 있는 디바이스만 Check File system을 1로 설정

2. File System

Mount Options

출처: file system mounting – linux (Youtube, The Linux Man)

2. File System

파일시스템 점검

리눅스 파일시스템의 자료에 문제가 없는지 점검하고, 에러나 손실이 있는 경우에는 복구해 준다

$ fsck –t [type] [device]

점검을 진행하기 전에는 파일 시스템이 언마운트 되어 있는 것이 권장

(루트 파일 시스템의 경우에는 사용 중에 언마운트가 불가능하므로 다른 OS에서 진행하거나(또는 bootable media로) GRUB에서 읽기전용, 단일 사용자 모드로 부팅하여 점검을 수행할 수있다.)

2. File System

파일시스템 만들어 보기 (실습)

[목표]

1. dd 커맨드를 이용하여 100MiB의 0으로 채워져 있는 빈 파일을 생성한다2. mkfs 커맨드를 이용하여 해당 파일 (디바이스 파일)을 ext4 fs로 포맷한다.3. mount 커맨드를 이용하여 해당 fs를 마운트한 다음, fdisk를 이용하여 파티션 생성 등 fs

내부에서 커맨드를 돌린다.4. 언마운트를 진행하여 root file system에서 해당 fs를 언마운트 한다5. 언마운트 상태에서 해당 파일을 삭제한다.

2. File System

파일시스템 만들어 보기 (실습)

1. dd 커맨드를 이용하여 100MiB의 0으로 채워져 있는 빈 파일을 생성한다

$ dd if=/dev/zero of=night_disk.fs bs=1024 count=102400

Input file = /dev/zero0으로 채워져 있는 device

Output file= night_disk.fs Block size = 1KiB(Sector size의정수배)

Block count1KiB * 1024 = 1MiB1MiB * 100 = 100MiB

2. File System

파일시스템 만들어 보기 (실습)

2. mkfs 커맨드를 이용하여 해당 파일 (디바이스 파일)을 ext4 fs로 포맷한다.

$ mkfs –t ext4 night_disk.fs # 또는 mkfs.ext4 night_disk.fs

• 참고-c 옵션: bad sector 검사

2. File System

파일시스템 만들어 보기 (실습)

3. mount 커맨드를 이용하여 해당 fs를 마운트한 다음, fdisk를 이용하여 파티션 생성 등 fs 내부에서 커맨드를 돌린다.

$ sudo mkdir /mnt/wheel$ sudo mount night_disk.fs /mnt/wheel

$ mount | grep night_disk.fs

$ cd /mnt/wheel && df -h

2. File System

파일시스템 만들어 보기 (실습)

3. mount 커맨드를 이용하여 해당 fs를 마운트한 다음, fdisk를 이용하여 파티션 생성 등 fs 내부에서 커맨드를 돌린다.

..? 여기서 loop device란?

Loop Device: Unix-like 시스템에서 파일을 마운트할 때 생성되는 pseudo-device. OS에서 loop device를 통해 해당 파일을 block device와 같이 접근할 수 있다.

주로 iso를 마운트 하거나 fs image를 관리할 때 매우 유용하게 사용함. Snap 패키지 관리자에서 앱 설치를 loop 디바이스를이용하여 한다고 함. (이런 방식은 Mac OS에서 앱 설치를 위해 dmg 이미지를 마운트 하는 것과 비슷한 방식이다. 이런 패키지의앱들은 사실 하나의 폴더이기 때문에 무언가 압축하여 설치할 수 있는 방법이 필요하고, 따라서 이를 disk image로 배포한 다음mount하는 형식으로 이용하는 것이다. → CD나 플로피 디스크에서 앱을 설치하는 것과 비슷한 느낌이다!)

$ losetup # loop device setup

2. File System

파일시스템 만들어 보기 (실습)

3. mount 커맨드를 이용하여 해당 fs를 마운트한 다음, fdisk를 이용하여 파티션 생성 등 fs 내부에서 커맨드를 돌린다.

$ sudo fdisk /dev/loop20

Command p (partition)

2. File System

파일시스템 만들어 보기 (실습)

3. mount 커맨드를 이용하여 해당 fs를 마운트한 다음, fdisk를 이용하여 파티션 생성 등 fs 내부에서 커맨드를 돌린다.

$ n # create new partition

파티션 번호. 최대 4까지 지원하는것을 보니 MBR을 이용하는 듯 하다

섹터 시작 섹터 번호

49MiB = (102400 – 2048)*512 bytes

섹터 종료 블록 번호 (K, M, G, T, P 를이용하여 10^n 단위를 이용할 수도있다)

* 아까 블록 크기를 1024MiB로 하였지만실제 물리적 디스크 (sda1)의 섹터는512MiB (뒤 슬라이드 참고)

2. File System

Sector, Block

Sector: 저장 장치의 최소 저장 단위 (512 byte / 4k byte)

$ fdisk –l

Block: fs에서 사용하는 블록의 최소 단위 (sector의 정수배) (Block 0)

예를 들어서 Bad Sector은 하드 디스크의 저장 단위에 정상적인 읽기/쓰기가 불가능해진 것을 의미한다.

2. File System

파일시스템 만들어 보기 (실습)

3. mount 커맨드를 이용하여 해당 fs를 마운트한 다음, fdisk를 이용하여 파티션 생성 등 fs 내부에서 커맨드를 돌린다.

$ w # 저장시 w, 저장 안하고 종료시 q

* 참고로 파일로 이루어진 디바이스의 경우 파티션 생성할 때, 각 device에 대해 각각 loop device를 만들어 주어야 한다.이럴 때 사용하는 것이 kpartx

$ sudo reboot # 저장 사항 반영하기 위해 재부팅

$ sudo apt install kpartx$ sudo kpartx –v –a night_disk.fs #-v: verbose, -a: add partition mappings

2. File System

파일시스템 만들어 보기 (실습)

3. mount 커맨드를 이용하여 해당 fs를 마운트한 다음, fdisk를 이용하여 파티션 생성 등 fs 내부에서 커맨드를 돌린다.

$ sudo mount –t ext4 /dev/mapper/loop20p1 /mnt/wheelp1$ sudo mount –t ext4 /dev/mapper/loop20p2 /mnt/wheelp2$ df -h

Loop20p1 (loop20 partition 1)디바이스가 생성된 것을 확인할 수있다.

$ mkfs –t ext4 /dev/mapper/loop20p1$ mkfs –t ext4 /dev/mapper/loop20p2

사용하는 mapper 마다 다르지만, 현재사용하고 있는 ubuntu 20.04의kpartx 에서는 /dev/mapper 안에loop device를 형성한다.

* 왜 다시 mkfs를 사용해야 할까? 파티션을 나누면 새롭게 생성된 파티션은 포맷이 되기 때문에 mkfs로 fs를 새로 생성해 주어야 한다.

2. File System

파일시스템 만들어 보기 (실습)

큰 파일을 새롭게 만든 fs 내부에 생성해 보자!

파일 복사를 위해 dd 커맨드를 사용할 수도 있지만, 비교적 느리므로 fallocate (데이터를 적지않고 inode 상으로만 disk 공간을 할당하는 커맨드)를 이용해 보자

$ sudo fallocate –l 30M /mnt/wheelp1/test.txt

df –h 커맨드로 확인해 보면 100% 사용되고 있음을 확인할 수있다!

$ sudo vim /etc/fstab

(Optional) Reboot 이후에도 자동으로 fs가 Mount되게 해보자!

$ ls /dev/mapper

2. File System

파일시스템 만들어 보기 (실습)

4. 언마운트를 진행하여 root file system에서 해당 fs를 언마운트 한다

$ sudo umount /dev/mapper/loop20p1$ sudo umount /dev/mapper/loop20p2$ df -h

A. Loop Device 언마운트

B. Loop Device 삭제

$ sudo kpartx –d –v night_disk.fs

Umount 한 김에 fsck로 device를 확인해 보자!

$ sudo fsck –t ext4 /dev/mapper/loop20p1

2. File System

파일시스템 만들어 보기 (실습)

5. 언마운트 상태에서 해당 파일을 삭제한다.

$ rm night_disk.fs

2. File System

Inode파일의 메타데이터를 저장하는 블록 (UNIX 기반 시스템의 특징, ext4, apfs 등에 해당)

Ext4의 Inode

Sleuthkit의 blkcat 명령어로 확인해 보자

$ sudo apt install sleuthkit

$ sudo fsstat /dev/sda1 # Inspect 하고 싶은 device를 선택하면 됨

그러면 Inode 범위 별로 Group으로 나누어져 있는 것을 확인할 수 있다..! -> 뒤에 더 자세히 나옴

2. File System

Inode원하는 파일의 inode를 알고 싶다면 ls 명령어에 –i (inode argument)를 붙여보자!

~$ ls –li

~$ touch test_inode.txt #test_inode.txt 를 생성

test_inode.txtinode 번호!

마찬가지로 directory도inode 번호를 가지고 있는것을 확인할 수 있다.

2. File System

InodeInode의 정보를 뜯어보면… (istat – inode stat)

$ sudo istat /dev/sda1 920533

/dev/sda1 (파일이 있는 디바이스)

해당 디바이스에서의파일 inode 번호 (이전 슬라이드 참고)

Istat에 오류가 있어서size: 0으로 나오는 것을 확인할 수 있다

Group: 112

2. File System

Inode다시 fsstat을 이용하여 group 112를 보자

920533번 Inode는 실제로 이 InodeRange 안에 있는 것을 확인해 볼 수 있다!

Data BitmapData Block 중 사용되고 있는block 들을 bitmp 형식으로표현한 것을 저장하고 있는block (0001000011111…)

Inode도 마찬가지

Ext4의 Inode 크기는 256byte 이다. (EXT2/3 는 128byte) 계산해 보면 (925696-917505+1)/(3670559-3670049+1) = 8192/512 = 161 block의 크기가 현재 4096byte 이므로 4096/16 = 256따라서 920533번 Inode는

920533 – 917505 = 30283028 / 16 = 189.25 → 3670048번 블록에서 + 190 offset 이므로 3,670,237 번블록에 아마 있을 것!

2. File System

InodeBlkcat으로 3,670,237 번 블록 덤프하기

$ sudo blkcat /dev/sda1 3670237 > blk-3670237

Hex Editor으로 blk-3670237 분석하기

$ sudo apt install hexedit # 또는 좋아하는 hex edito을 사용해도 된다$ hexedit blk-3670237

아까 .25 에서 이 블록의 4번째 inode라는 뜻이므로 4번째를 확인해 보자

2. File System

Inode[참고] bytes52 – 55: Logical block number56 – 57: Number of blocks in extent58 – 59: Upper 16 bits of physical block60 – 64: Lower 32 bits of physical block

$ nano test_inode.txt

지금은 데이터가 아무것도 없으니 block 이 0으로 뜬다.

“ I am SPARCS data!” 를 입력해 보자

2. File System

Inode다시 block을 dump하여 hexedit으로 확인해 보면

Data가 바뀌었다! (예~)

[참고] bytes52 – 55: Logical block number→ 0x000056 – 57: Number of blocks in extent→ 0x0001 (little endian)58 – 59: Upper 16 bits of physical block→ 0x0000 60 – 64: Lower 32 bits of physical block→ 0x0029A0AA (little endian)

Ext4는 48-bit 블록 주소를 이용한다. (그래서 아까 istat에서 오류가 났던 것…)

이를 블록 번호로 바꾸어 보자!→ 0x0029A0AA = 2,728,106

2. File System

Inode이론적으로 블록 번호 2728106에 우리의 데이터가 있어야 한다!

$ sudo blkcat /dev/sda1 2728106

2. File System

Inode디지털 포렌직 전문가가 되어서 삭제된 파일의 정보를 복구해 보자

$ rm test_inode.txt

Inode가 있던 블록을 덤프해 보면

$ sudo blkcat /dev/sda1 3670237 > blk-3670237

(다른 프로그램이 해당 inode를 사용한 듯 하다)

2. File System

Inode

확인해 보니까 systemd가 사용하였다!

$ sudo blkcat /dev/sda1 2728106

뭐 그래도 다시 원래 test_inode.txt가 있던 데이터 블록을 확인해 보면

중요한 파일이라면 삭제해도 안전한 것이 아니다!

2. File System

Inode / Group

아까 Inode가 Group에 있는 것을 확인할 수 있었다. Group은 무엇일까?

Ext4는 데이터 블록이 Group에 Align 될 수 있도록 열심히 노력한다- Defragmentation에 이점이 있고, Context Switching을 피할 수 있기 때문!

2. File System

Inode / File Name

흠 그런데 왜 아까 hexdump를 했을 때 파일명은 없었을까?

EXT4 에서는 파일명이 Inode에 저장되지 않고, directory의 data에 포함되기 때문!

This directory

Parent Directory

2. File System

Inode / File Name

Directory에는 파일명과 inode 주소들이 저장된다.

$ sudo debugfsdebugfs: open /dev/sda1debugfs: blocks . # 9252debugfs: bd 9252 # block dump

* 물론 아까와 같은 방법으로 할 수 있지만 귀찮으니까debugfs를 사용하자!

debugfs: q # quit

2. File System

Indirect BlocksPrior to Ext4 (작은 파일들이 많았던 시절… 4TB를 어떻게 채우지???)@ Inode Block 0x28 Indirect block pointer

Block Pointer (each pointer is 4byte, with 4K block size 1024 pointers)

Up to 12 * 4k = 48K

Up to 48K + 1024 * 4k = 48M

Doubly indirect pointer

file

file

Tells the fs to traverse twice. (b.c. we cannot know if the second block is a data block or a block pointer (garbage in a sense))

Up to 1024*1024*4K = 4GB

Trebly indirect pointerUp to 4TB

https://www.sans.org/blog/understanding-indirect-blocks-in-unix-file-systems/

2. File System

Indirect Blocks하지만 이러한 접근은 현대 OS에서 사용하기에 단점이 많다.

1. 4TB 이상의 파일 생성 불가2. 대용량의 파일의 경우 (4MB 이상은 2번의 pointer 연산, 4GB

이상은 3번) 효율적으로 데이터 블록에 접근할 수 없다3. 데이터 블록의 연속성을 장려하지 않음.

[참고] 과거 UNIX의 디스크는 다음과같은 형태로 data block과 inodeblock을 하드디스크 상에 분포했다고 함

(플래터에서 접근하기 보다 쉬운 형태)

http://pages.cs.wisc.edu/~bart/537/lecturenotes/s24.html

2. File System

Extent Trees (EXT4)EXT4는 기존 EXT2/3 와 여러 차이점이 있다.

https://www.sans.org/blog/understanding-ext4-part-3-extent-trees/

48bit address, contiguous blocks 등등…

가장 대표적인 차이는 Indirect Blocks → Extent Trees 로의 변경! Magic Number와 Flag를 적절히 이용하여backwards-compatibility를 어느 정도 유지하기는한다. (일부 metadata가 고장나는 정도)다시 파일을 하나 만들어서 inode를 뜯어 보자! (좀 크게)

$ dd if=/dev/zero of=test.txt bs=1024 count=4096000 #4GB

2. File System

Extent Trees (EXT4)Inode block 번호 구하기

https://www.sans.org/blog/understanding-ext4-part-3-extent-trees/

$ sudo debugfsdebugfs: open /dev/sda1debugfs: imap /home/jiho/test.txt # 로 inode 번호를 찾고 여기서 hexdump를 해도 되지만

debugfs: id /home/jiho/test.txt # 로 바로 hexdump 가능! (근데 잘 안되는 것 같다)

$ sudo blkcat /dev/sda1 3670109 > blk-3670109

2. File System

Extent Trees (EXT4)

https://www.sans.org/blog/understanding-ext4-part-3-extent-trees/

i_block 데이터

0xf30a Magic Number (extent tree)0x0001 Number of valid ext.0x0004 Max. number of ext. (should be 4 in ext4)0x0001 Depth of this extent node- 0: this node points to

data blocks- 1~5: this node points to

other extent nodes0x00000000 Gen ID (not used by ext4)

2. File System

Extent Trees (EXT4)

https://www.sans.org/blog/understanding-ext4-part-3-extent-trees/

i_block 데이터

이 블록의 depth !== 0 이므로Internal Node 이다.

0x00000000 Logical Block #0x003885b0 Lower 32 bits0x0000 Upper 16 bits0x002b Not used

$ sudo blkcat /dev/sda1 3704240 > blk-3704240

그 다음 extent block을 확인해 보자

2. File System

Extent Trees (EXT4)

https://www.sans.org/blog/understanding-ext4-part-3-extent-trees/

0xf30a Magic Number (extent tree)0x002d Number of valid ext.0x0154 Max. number of ext. (4096/12=341 – 1 = 0x154) # 12byte nodes, 1 12byte header0x0000 Depth of this extent node- 0: this node points to data blocks- 1~5: this node points to other extent

nodes0x00000000 Gen ID (not used by ext4)

이 블록의 depth === 0 이므로Leaf Node 이다. (data block으로의 포인터)

0x00000000 이 extent가 표현하는 첫 번째 파일의블록0x0800 연속적인 블록의 개수 #2048 (최대 길이는32767)0x0000 Upper 16 bits 0x002b8000 Lower 32 bits

이 블록의 depth === 0 이므로Leaf Node 이다. (data block으로의 포인터)0x00000080 이 extent가 표현하는 첫 번째 파일의 블록 (주황색에서 0x80개를 이미 했으므로)0x0800 연속적인 블록의 개수 #2048 (최대 길이는 32767)0x0000 Upper 16 bits 0x002b9000 Lower 32 bits

2. File System

Extent Trees (EXT4)

https://www.sans.org/blog/understanding-ext4-part-3-extent-trees/

아까 0x002b8000 ~ 0x002b8800, 0x002b9000 ~ 0x002b9800 에 데이터가 저장되어있어야 하므로, 확인해 보자!

$ sudo blkcat /dev/sda1 2850816 > blk-2850816 #0x002b8000

$ sudo blkcat /dev/sda1 2852688 > blk-2852688 #0x002b8750

2. File System

Extent Trees (EXT4)

https://www.sans.org/blog/understanding-ext4-part-3-extent-trees/

근데 아가 여기에서 왜 valid ext. 는 1개인데 뒤에garbage 데이터와 같이 계속 있을까?

잘 생각해 보면 file pointer 에서 계속파일의 크기를 증가시킬 때, inode 내부의ext만으로는 부족하여 extent tree 를 형성(inode의 level을 1로 설정하고, level 0인블록을 새로 할당하여 연결) 할 필요가있었을 것이다!

이 때, inode의 ext에서 extent node로extent를 옮기는 과정에서 inode의 valid ext. 숫자만 수정하고 데이터는 지우지 않음! (lazy)

성능 향상에는 도움이 되겠지만… 확실히hexdump로 디버깅하기에는 곤란하다

2. File System

EXT4’s Aggressive Block Allocation Policy

https://www.kernel.org/doc/html/latest/filesystems/ext4/overview.html

EXT4는 매우 공격적으로 같은 파일의 블록을 연속적으로, 그리고 같은 Group 안에 할당하기 위해노력한다.

- 회전하는 디스크 (HDD)의 경우, 데이터 seek 시간이 감소함- SSD의 경우, controller에 단일 섹터의 데이터만 요구해도 되므로 throughput이 증가함- 전반적으로 fs 의 복잡도가 감소하고, 쓸데없는 tree traversal이나 포인터 연산을 안해도 됨. - Block 위치를 저장하는 메타데이터 공간을 절약할 수 있음

이를 위해 다음과 같은 policy가 있다.

- [ 1 ] Multi-block allocator 처음 파일이 생성될 때 8KiB는 바로 채워질 것을 예상하고 연속적으로 할당. File Pointer가닫히는 경우에는 빈 공간으로 남겨지지만, 성공할 경우에는 연속된 공간에 파일 데이터가 들어가게 됨

- [ 2 ] Delayed Allocation 파일이 더 많은 블록 할당을 요구할 경우, RAM에 변경 사항을 저장하고 실제 디스크로 write 하지 않음. (write는 포인터가 종료되거나 commit timeout 초과, sync() 발동, 메모리 부족 등의 상황에서 발동함) 파일의 전체 크기에 대한 정보가 주어지면 fs가 보다 적절한 블록 위치를 선정할 수 있을 것이라 기대

- [ 3 ] Same group as inode (ext3, 4) 파일의 데이터 블록은 최대한 inode와 같은 block group 에 저장된다. - [ 4 ] Directory Grouping 한 디렉토리의 파일들은 같은 block group 안의 inode를 같게 노력한다. (따라서 비슷한

번호때의 inode를 확인할 수 있다) 루트 파일 시스템의 경우, 디렉토리들의 inode를 최대한 먼 group들에 배치하려고한다. (이 때 hdd의 경우 한 디렉토리가 플래터의 끝부분에 위치하게 되어 페널티를 얻을 수 있다…)

- [ 5 ] 128MB Block Groups 블록 그룹으로 fs를 나누면 효과적이다. 한 블록 그룹이 꽉 차면 보통 다음 그룹으로넘어가서 write 하게 된다. Ext4는 이런 data locality를 유지하기 위해 거의 상시적으로 defrag를 진행함.

2. File System

Types of File Systems

2020 Summer Wheel Seminar by Jessie

Microsoft Windows ™ : FAT 16, FAT 32, NTFS

Linux : Btrfs, EXT2, EXT3, EXT4, ReiserFS (저작권 문제 때문에…), XFS

MacOS ™ : HFS/HFS+ , APFS

UNIX – like!

2. File System

Linux File Systems

2020 Summer Wheel Seminar by Jessie

EXT (Extended File System)

EXT2 – 과거에 널리 사용

EXT3 – EXT2 에서 Journaling 지원 (EXT2 에서 –j를 키면 EXT3가 됨, 완전 호환)

EXT4 – Extents, Data locality (요즘 안드로이드에서도 사용, 가장 흔함)

Journaling

파일 변화를 바로 디스크에 commit 하는 것이 아니라, 우선 Journal 영역에 변경 이력을 쓰고 디스크에저장한다. (EXT2, FAT16/32 제외)파일 수정 중 Crash가 일어나면 파일의 부분 버전이다른 inconsistency 문제나 불완전한 삭제 등의문제를 해결할 수 있음

- 최대 1EB 공간, 최대 16TB 파일- Extent: 새로운 공간 할당 방법- 하위 호환성: EXT2, 3도 지원- 지연된 할당: allocate-on-flush- 하위 디렉토리 제한 없음 (기존까지는 32000)

2. File System

Mac File Systems

APFS: High Sierra 부터 지원, SSD 최적화

- High Sierra 업데이트 과정에서 자동으로 Mac의 디스크를 HFS+ 에서 APFS로 전환함- 보다 빠른 metadata 접근 및 계산 (한 곳에 모아서 정리함)- 파일 복사시 같은 데이터 위치로 포인터 2개 생성. 한 파일이 수정될 경우 복사본을 저장함- ‘빈 파일’ 할당시, 0으로 초기화하지 않아서 보다 빠르게 앱에서 할당 가능- ‘Copy-on-write’ 지원: 메타데이터 수정할 경우, 복사본에 작성한 다음, 포인터를 변경 (ZFS, BtrFS, ReFS에서 소개된 기능)- Checksum 강화, file snapshot (변경 사항만 기록)으로 time machine과의 연동성 강화- T2칩을 이용한 encryption 강화- APFS 내부의 ‘space-sharing’을 이용하여 APFS 내부에 다른 fs의 볼륨 생성 가능

https://www.howtogeek.com/327328/apfs-explained-what-you-need-to-know-apples-new-file-system/

HFS+ (Mac OS extended): Fusion Drive 및 HDD에 최적화

- 1998년도 출시, Journaling 등의 기능을 지원함

ExFAT: Windows에도 사용해야 하는 드라이브를 위한 파일 형식

2. File System

Windows File System

FAT 16/32 ExFAT

- FAT의 파일들은 ‘클러스터’라는 블록들에 저장됨- 이 클러스터를 어떻게 이으면 하나의 파일이 나오는지 설명하는 것이 FAT (File Allocation Table)!- FAT는 파일들이 어떻게 이어져 있는지 표현하는 linked list (-1은 파일의 끝을 의미)- 파일 시작 위치를 표현하기 위해 ‘Directory File Format’ 이라는 것이 존재. (이것도 하나의 파일!)- 이 Table에 있는 entry는 모두 같은 데이터 크기를 가지고 있으며, 파일명, 시작 블록, 메타데이터를 저장- 디렉토리도 하나의 파일… 디렉토리 내부에는 Directory File format의 데이터가 있음- Fat 16/32/64는 한 클러스터의 크기와 메타데이터의 크기를 결정함- ExFAT은 ‘extended’로 보다 큰 파일 크기들을 지원함

https://www.youtube.com/watch?v=V2Gxqv3bJCk

NTFS

https://www.youtube.com/watch?v=xW5UwDztkX4

- Windows NT (Windows Server 2000 부터 사용한 커널)을 위한 파일시스템- MFT (Master File Table)로 파일들을 관리함 (메타데이터, 이름, 블록 위치들이 여기에 저장됨)- Journaling 지원- NTFS 파일 헤더는 0x46494C45 (FILE) 로 시작- 512 byte 미만의 파일은 MFT 레코드의 lower 512 byte의 저장됨 (resident),- 아니면 클러스터 번호가 저장 (Cluster Chain)

2. File System

Windows File System

Cluster Chain

https://www.youtube.com/watch?v=xW5UwDztkX4

12 FA 04 2D 00

Number of bytes to the immediate right which will provide the number of clusters in this series (decimal)

(2)

Number of bytes which immediately follow the cluster run bytes

(1)

Chain end (0x00)

따라서 이것은 총 0x04FA (little endian) 개의 sector 가 연속적으로 있음(1274 * 4096 bytes = 5.2MB)

또, 시작 클러스터 번호는 0x2D (45)

2. File System

Windows File System

Resident files, Non-resident files

Disk 파일 크기가 0바이트!

이런 현상이 일어나는이유는 바로 아까 NTFS 설명하면서 나온 ‘resident files’의 개념 때문… MFT에 바로 파일데이터를 (충분히 작을경우) 저장하여 디스크(블록)을 할당 안해서생기는 현상!

2. File System

Windows File System

Resident files, Non-resident files (선택… 프로그램 설치가 복잡하다…)

$ nfi [ filename ] 하면 NTFS 정보를 확인할 수 있다!

http://www.jumpjet.info/Application-Software/Windows/win2k.htm 에서 oem3sr2.zip 다운

파일 크기가 충분히 커지면 $DATA가 nonresident로 바뀌는 것을 확인할 수 있다(참고로 다시 resident로 돌아가지는 않음)

https://www.youtube.com/watch?v=q6eCv0plATg&t=437s 참고

2. File System

File System 참고

참고로 빈 Disk를 포맷할 때 저장공간 일부가 남는 이유는 File System이 해당 공간을 잡아먹기 때문!

→ 따라서 영상이 딱 4GB이어서 4GB짜리 USB에 넣으려 하면 곤란할 수도 있다

추가적으로 Disk가 거의 꽉 차면 OS가 느려지는 이유는 파일 write를 할 때 새로 할당할 공간을 찾는데오래 걸려서 그렇다. 또, 섹터가 fragmented 되어지므로 더욱 느려질 수 밖에 없다.

→ 저장 공간은 넉넉하게 구매하자

Linux 에서는 root에게 항상 5% 잔여 fs 공간을 제공한다. (디스크가 꽉 차도 명령어 실패를 수습할 수 있도록) 하지만 디스크 크기가 점점 커지고 있어서 낭비되고 있다고…

Swap

3. Swap

Swap이란

메모리는 빠르고 많을 수록 좋다!

CPU 캐시를 늘리는 것은 좋은 CPU를 사면 되는데좋은 CPU는 엄청 비싸다 (CPU 1개가 200 이상…)

그럼 램 용량을 늘리는 것도 여러가지 작업을 동시에 해야하거나 딥러닝 같이 메모리가 많이 필요한 경우 유용할 수있다.

그러나… 램 가격도 만만치 않고 램을 계속 늘리는 것이 좋은해결책이 아닌 경우도 있다!

따라서 메인 메모리의 페이지를 swap space로 이동하여시스템에서 사용 가능한 메모리의 양을 늘리는 것을Swapping 이라고 한다.

3. Swap

Swap이란

Swap Space: 시스템에서 사용 가능한 메모리 양을 늘리기 위해 디스크에 준비되어 있는 공간

Swapping : 메인 메모리의 페이지를 swap space로 이동

- 커널에서 자주 사용되지 않는 페이지를 swap space로 이동

Paging : CPU는 항상 Logical Address (Virtual Address)를 생성한다

2017 Wheel Seminar - Moonde

https://www.studytonight.com/operating-system/paging-in-operating-systems

https://www.geeksforgeeks.org/paging-in-operating-system/

따라서 Logical Address를 실제 메모리 주소인Physical Address로 변환하는 방법이 필요! 이를 담당하는 기기가 MMU (Memory Management Unit)

3. SwapSwap이란

2017 Wheel Seminar - Moonde

https://www.studytonight.com/operating-system/paging-in-operating-systems

https://www.geeksforgeeks.org/paging-in-operating-system/

Physical Address Space는 고정된 블록들인Frame으로 나누어져 있다.

Logical Address Space 는 고정된 블록들인 Pages로나누어져 있다.

여기에서 Frame size == Page size

CPU는 Page Number (p)와 Page Offset (d)를형성한다. 이를 이용하여 MMU는 Frame Number (f)와 Frame Offset (d)를 물리적 메모리에서retrieve 함

왜 이렇게 복잡하게 하지?

예를 들어서 C++로 프로그램을 만들어서 포인터의 값을 읽는다고 생각하자. 이 메모리 주소는 Virtual Address (현대 OS에서는) 이며, 이를 Page Table을 이용하여 물리적인 주소로 변환해야 한다! (그러니까 &a ++ 해도 실제 물리적 주소에서는 불연속일 수도 있다는 것)

1. 보안 (각 프로그램 마다 Address Space가 달라 메모리 접근 불가능)2. Caching & Paging의 효율 (프로그램은 캐시/페이징이 어떻게 진행되는지 몰라도 됨)3. 불연속적 물리적 메모리 주소 할당 가능! (프로그램이 여러 개 실행되면 fragmentation…)

3. Swap

Swap이란

Thrashing: Swap out과 Swap In 이 계속해서 발생하는 현상

2017 Wheel Seminar - Moonde

리눅스에서는 권장이 아니지만 있는 것이 좋다.(RAM이 작은 경우 RAM * 2, 비교적 큰 경우는 RAM * 1, 딥러닝 하면 RAM *2 이상)

윈도우에서는 자동으로 OS가 관리해 준다! (메모리가 부족하면 페이지 증가 등)참고로 Win98 시절에는 RAM double 해준다는 것들이 대부분 paging이나 메모리 압축 도구였다고 함

맥OS에서도 OS가 자동으로 관리해 준다!M1이 빠른 이유 중 하나가 SoC 위에 CPU, 메모리, SSD 사이의 거리가 매우 짧고 Swap을 매우 공격적으로 하기 때문(그렇지만 SSD 수명이… 커흑)

Swap Partition: Swapping만을 위한 파티션으로 Swap만 존재 가능!Swap File: File System 안에 Swapping을 위한 파일을 생성하는 것 (파티션 내부에 생성)Swap Partition이 연속적인 섹터에 할당되어서 성능적인 면에서는 좋다고 함, 일반적으로 Swap Partition 사용

3. Swap

Swap Space 관리

2017 Wheel Seminar - Moonde

$ free # htop ㅎㅎ..

현재 메모리 상태 확인

• Kb 단위로 표시됨, mb 등은 $ free –m• Total: 전체 메모리, Used: 사용 중인 메모리, Free: 사용 중이지 않은 메모리, Shared: 주로 tmpfs에 의해 사용,

Buffers: 커널 버퍼 (아까 ext4 버퍼 등), Cache: 페이지 Cache와 Slabs에 의해 사용, • Available: (커널마다 다름) Swapping 없이 새로운 application을 실행할 수 있는 메모리의 크기

버퍼와 캐시는 성능 향상을 위해 사용되는 것이기때문에 메모리가 부족할 경우 user application에의해 사용될 수 있다

(그런데 커널이나 fs등이 느려질 것이다)

3. Swap

Swap Space 관리

2017 Wheel Seminar - Moonde

$ dd if=/dev/zero of=swapfile bs=1024 count=102400

Swap File 만들기 (실습)

1. Swap 파일을 위한 파일을 생성한다 (100 MiB)

3. Swap

Swap Space 관리

2017 Wheel Seminar - Moonde

$ chmod 0600 swapfile

Swap File 만들기 (실습)

2. 권한 변경 (Swap에는 메모리 데이터가 들어가므로 root user만 읽고 쓸 수 있게 해야함)

$ sudo chown root swapfile

3. Swap

Swap Space 관리

2017 Wheel Seminar - Moonde

$ mkswap swapfile # -c 옵션: bad block 있는지 확인

Swap File 만들기 (실습)

3. Parition이나 File을 swap space로 포맷

참고로 새로운 파티션을 swap으로 만들기 위해서는 위에서 썼던 fdisk를 이용하면 된다.

$ sudo fdisk [device]

$ sudo fdisk –l # swap으로 설정되어 있는지 확인

3. Swap

Swap Space 관리

2017 Wheel Seminar - Moonde

$ sudo swapon [swap partition / swap file]

Swap File 만들기 (실습)

4. Swap Space 활성화

-a 옵션을 추가하면 /etc/fstab에 추가해 부팅시 자동으로 추가해 준다.

$ swapon -s

3. Swap

Swap Space 관리

2017 Wheel Seminar - Moonde

$ free

Swap File 만들기 (실습)

5. Swap 추가된 것을 확인

3. Swap

Swap Space 관리

2017 Wheel Seminar - Moonde

$ sudo swapoff swapfile

Swap File 만들기 (실습)

6. Swap 해제

$ swapon -s

$ free

Swapfile 삭제전 꼭 swapoff를 해주자!

Device File

4. Device File

Device Files & Device Drivers

https://unix.stackexchange.com/questions/101759/difference-between-device-file-and-device-drivers

DeviceFiles

DeviceDrivers

FS의 디바이스 파일- 메이저 장치 번호: 커널의 드라이버 지정- 마이너 장치 번호: 드라이버의 장치 지정

하드웨어 인터페이스를Abstraction 해줌

Application은Device File로

상호작용

8: Major Device Number1: Minor Device Number

4. Device File

Device Files & Device Drivers

따라서 Device File을 만든다고 해도 Driver가 없으면 아무 의미가 없다!

→ Everything is a file에 의해 device도 파일이지만, device file만 있는 것은 아무 의미가 없는 것

→ Device File도 하나의 Abstraction으로 생각하자!

그럼… 실습을 해봅시다 ^^

4. Device File

Device Files & Device Drivers

$ ls /dev/

→ 장치파일 보기

$ mknod

→ 장치파일 만들기

$ ln -s

→ Symbolic link 만들기

$ rm

→ 장치파일 삭제하기

[ 참고 ] Symbolic Link은 Inode상에서 바로 다른 파일의 link로 처리됨!

4. Device File

Creating a Device File

1. 장치파일 생성하기

$ sudo mknod –m [permissions] [name] [type] [major] [minor]

Name: 만들 장치명 (ex: /dev/night0)Type: 문자 장치는 c, 블록 장치는 b (15번 슬라이드 참조)Major: 장치의 메이저 번호Minor: 장치의 마이너 번호-m permissions: (optional) 장치 파일의 퍼미션 설정 (ex. –m 777)

$ sudo mknod /dev/night0 b 8 0

→ 아까 확인했을때 8번 Major Number가 storage driver이었으니까 이러면 storage로 인식할 것!

4. Device File

Creating a Device File

2. 실제 storage 처럼 작동하는지 확인

$ sudo fdisk /dev/night0

/dev/sda1의 정보가 뜬다!

Major Number 8, Minor Number 0 이 똑같기 때문에driver에서 /dev/sda1 처럼취급하기 때문

[주의] Device File도 chmod 0600으로 root만 read, write 할 수 있게 하자!

4. Device File

Creating a Device File

3. Symbolic Link 만들기

$ ln –s [원본 파일명] [타겟 파일명]

$ ln –s harddisk /dev/night0

/dev/night0 의 정보가 뜨는 것을확인할 수 있다!

4. Device File

Creating a Device File

4. Symbolic Link 제거하고, 장치파일 삭제하기

$ rm harddisk

$ sudo rm /dev/night0

[ 참고 ] 장치 파일을 제거한다고 해서 메모리나 커널에서 장치가 제거되는 것은 아니다! (reference만 제거한 것)

존재하지 않는 드라이버를 이용하려고 하면No such device or address 오류가 뜨는 것을 확인할수 있다

Physical Disk

5. Physical Disk

SSD

Solid State Drive

2021 Winter Wheel Seimar - Nenw

구성 요소메모리 (MLC / TLC / QLC)DRAMController

Read, Write Maximum Cycle이 존재가장 중요한 것은 Write!

(NAND의 상태가 바뀌면 수명이 짧아짐)

높은 대역폭, Low Latency비교적 무작위 접근에 강력함

(하지만 같은 칩 내부의 데이터를 접근하면controller의 효율이 좋아지기 때문에 유리)

AWS EBS에서 SSD 사용함

5. Physical Disk

HDD

Hard Disk Drive

2021 Winter Wheel Seimar - Nenw

구성 요소플래터 (CMR/SMR)헤드 (여기에서 데이터를 읽는다)

Read, Write Maximum Cycle이 존재물리적으로 동작하는 부품들이 많다따라서 보통 헬륨/네온 포장되어 있음

비교적 싼 GB당 가격으로 NAS나 데이터 드라이브로적합. 하지만 Random Read/Write는 SSD보다 많이느림 (OS 부팅하면…) Continuous Write/Read는 꽤빠름 (큰 파일에 적합)

하지만 배드섹터, 스틱션, 진동 등의 문제를 고려해주어야 함

5. Physical Disk

HDD

HDD는 언젠가는 사망하게 되어 있고, 이는 예측하기 어려움

2021 Winter Wheel Seimar - Nenw

S.M.A.R.T 를 이용하여 사망 가능성을 확인할 수 있음

5. Physical Disk

S.M.A.R.T

2021 Winter Wheel Seimar - Nenw

자가 모니터링, 진단 분석, 보고 기술

주요 지표보류 중인 섹터 수 (Current_Pending_Sector)재할당 이벤트 수 (Reallocated_Sector_Ct)회복 불가능 섹터 수 (Offline_Uncorrectable)읽기 오류율 (Raw_Read_Error_Rate) 등등…

뭔가 잘 안써지고 읽어진다면 곧 죽는다는 것이다

smartmontoolsS.M.A.R.T 읽기 및 메일 발송

$ smartctl –a [device file]

5. Physical Disk

SSD + HDD

2021 Winter Wheel Seimar - Nenw

애플이 부르는 Fusion Drive

SSD는 빠르지만 비싸고, HDD는 느리지만 GB당 싸기 때문에 2개를 동시에 달면 단점 보완 가능!

2021년 기준 중~고가형 시스템에는 SSD 256GB~512GB + HDD 1~3TB 가 국룰

당연히 OS와 자주 쓰는 프로그램 (Daemon이 자주 동작하는 것들)은 SSD에 넣어야 한다

5. Physical Disk

Magnetic Tape

2021 Winter Wheel Seimar - Nenw

AWS Glacier와 같은 데이터 장기 보존에 이용

매우 읽기/쓰기가 느리고 테이프 위에 있어서 Random Access도 안되지만 반영구 보존 가능!(물론 읽기 기술이 남아있다면)

5. Physical Disk

DNA Drive (미래기술)

2021 Winter Wheel Seimar - Nenw

최근 MS에서 DNA에 데이터를 넣는 기술을 발명하였다고 한다.

데이터 밀도가 매우 높고 전력 효율 또한 높을 것으로 기대

Self-healing도 가능

5. Physical Disk

LVM (Logical Volume Manager)

2021 Winter Wheel Seimar - Nenw

Linux에서의 Device Mapper Framework로 여러 (혹은 단일) Physical Disk를 하나의 가상드라이브로 만들어 사용하는 것

On-demand로 디스크 크기를 증가하거나 줄일 수 있다는 것이 장점이고, 다른 Physical Disk로Logical Disk를 옮기는 것도 가능하다. (VM 등에 매우 유용하게 쓰인다!)

SSD / HDD를 이용한 Hybrid Volume 또한 생성 가능하다

뒤에 나오는 RAID 또한 지원한다! (RAID 1, 5, 6)

5. Physical Disk

RAID (Redundant Array of Independent Disks)

2021 Winter Wheel Seimar - Nenw

여러 물리적인 드라이브를 하나의 Logical Unit으로 묶는 기술

데이터를 어떻게 분할하는지에 따라 RAID의 장점이나 특징이 달라진다.

일반적으로 가용성 및 성능을 높이는데 이용!

5. Physical Disk

RAID (Redundant Array of Independent Disks)

2021 Winter Wheel Seimar - Nenw

RAID 0

Mirroring, Parity 없이 단순 Striping만 지원

N개의 디스크에 동시에 읽기 쓰기 분산 (데이터가 나누어서 들어감) → Concurrent R/W 가능

N개의 디스크가 하나의 드라이브가 되어서 100% 저장공간을 쓸 수 있고 매우 빠르지만

하나의 디스크만 날아가도 복구 불가능

RAID 1

Striping, Parity 없이 단순 Mirroring 지원

같은 데이터가 N개의 디스크에 똑같이 들어감. N-1개의 디스크가 망가져도 문제 없음

Write에서는 이점이 없지만 Concurrent Read 가능 (같은 데이터니까)

저장공간 효율이 매우 좋지 않음

5. Physical Disk

RAID (Redundant Array of Independent Disks)

2021 Winter Wheel Seimar - Nenw

RAID 5

최소 3개의 디스크가 요구되며, Parity를 저장한다.

Parity 정보가 모든 디스크에 분산되어 저장되기 때문에 1개의 디스크 fail까지 복구 가능

하지만 Rebuilding 과정에서 모든 disk에서 계속 Read 해야 하기 때문에 2차 fail 가능성 증가

복구 과정에서의 성능 하락 매우 심함

RAID 6

최소 4개의 디스크가 요구된다

Double Distributed Parity 를 이용하여 최대 2개의 디스크 fail 까지 복구 가능

디스크 용량이 커지거나 array 크기가 증가하면 RAID 5 대신 RAID 6를 이용하는 것이 더 좋다!

(특히 여러 Manufacturer의 Disk를 이용하는 경우라면)

5. Physical Disk

RAID (Redundant Array of Independent Disks)

2021 Winter Wheel Seimar - Nenw

Nested RAID

한가지 이상의 종류의 RAID를 tree 형태로 이용하는 것

원하는 수준의 안정성, 성능, 저장용량을 선택하여 RAID를 제작할 수 있다!

[ 참고 ]

RAID를 설계할 때 미리 용량을 정해 두는 것이 좋다.

RAID에 Disk를 추가하려고 하면 (특히 RAID 5, 6)

데이터를 그냥 새로운 RAID에 복사하는 것이 빠르기 때문이다

5. Physical Disk

RAID (Redundant Array of Independent Disks)

2021 Winter Wheel Seimar - Nenw

소프트웨어 RAID

RAID 디스크 관리를 소프트웨어 상에서 진행하는 것 (Controller가 OS)

장비를 구매하지 않아도 되지만, 성능은 떨어짐

$ mdadm # RAID 설정 명령어

5. Physical Disk

RAID (Redundant Array of Independent Disks)

2021 Winter Wheel Seimar - Nenw

하드웨어 RAID

물리 RAID Controller을 이용하여 RAID 구현

미러에서 사용중인 Avago MegaRAID 등이 있음

$ sudo MegaCli # MegaRAID 설정 명령어

Smartmontools로 S.M.A.R.T 읽기

$ sudo smartctl –A --device=sat+megaraid, (번호) /dev/sdb

[ 참고 ]

여러 HDD가 들어가는 NAS 나 백업 서버 등을 제작할 경우, NAS용 드라이브를 구매하는 것이 좋다

HDD의 진동으로 공진이 일어나서 fail이 일어날 수 있기 때문! (NAS용은 이런 환경에 대비하여 설계되어 있다)

감사합니다