물리적으로 분리된 2개의 드라이브를 한 개의 드라이브 처럼 쓰고 싶을 때가 있다. 특히 오래된 노트북에서 적은 용량의 SSD와 HDD가 함께 장착되어 있을 경우 HDD를 SSD로 바꾼 후 그렇게 쓰고 싶은 마음이 무럭무럭 자라게 된다.
보통 이런 목적으로 사용하게 되는 게 LVM 인데 이게 좀 불편하다. 레이어 비슷하게 여러 단계로 나뉜 계층 구조를 따라야 하고 사용하는 명령어도 좀 그렇고...
그래서 좀 찾아보니 BtrFS에서 이렇게 분리된 드라이브를 하나로 합쳐서 1개의 드라이브로 쓸 수 있다고 해서 실험해봤더니 아주 잘 작동한다.
부수적으로 2개의 드라이브에 데이터 블록을 분산해서 실제 억세스 속도도 좋아지는 모양이다.
다만 이렇게 합친 드라이브 중 하나가 깨지면 전체가 깨진다. 이게 좀 불안한 문제이긴 한데 어차피 오늘만 살아가고 있으니 상관 없다.
sudo btrfs device add /dev/sdb /
/ 디렉토리에다가 2번째 드라이브를 합치는 명령이다. 간혹 강제로 붙이기 위해 -f 옵션을 추가해야 하는 경우도 있다. (내 경우는 늘...)
sudo btrfs device add -f /dev/sdb /
이렇게 붙이고 나면 일단 2개의 드라이브가 하나로 합쳐져서 보이게 된다. 예를 들자면 아래와 같이 분리된 드라이브가 하나로 보인다.
debian ~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sdb 8:0 0 238.5G 0 disk
zram0 254:0 0 7.7G 0 disk [SWAP]
nvme0n1 259:0 0 238.5G 0 disk
├─nvme0n1p1 259:1 0 953M 0 part /boot/efi
└─nvme0n1p2 259:2 0 237.5G 0 part /opt
/tmp
/var
/.snapshots
/home
/
debian ~ $ df -H
파일 시스템 크기 사용 가용 사용% 마운트위치
udev 8.3G 0 8.3G 0% /dev
tmpfs 1.7G 1.8M 1.7G 1% /run
/dev/nvme0n1p2 512G 61G 448G 12% /
tmpfs 8.3G 26M 8.3G 1% /dev/shm
efivarfs 132k 47k 80k 37% /sys/firmware/efi/efivars
tmpfs 5.3M 8.2k 5.3M 1% /run/lock
tmpfs 1.1M 0 1.1M 0% /run/credentials/systemd-journald.service
/dev/nvme0n1p2 512G 61G 448G 12% /home
/dev/nvme0n1p2 512G 61G 448G 12% /.snapshots
/dev/nvme0n1p2 512G 61G 448G 12% /var
/dev/nvme0n1p2 512G 61G 448G 12% /tmp
/dev/nvme0n1p2 512G 61G 448G 12% /opt
/dev/nvme0n1p1 998M 9.2M 989M 1% /boot/efi
tmpfs 1.7G 148k 1.7G 1% /run/user/1000
debian ~ $
lsblk 명령으로 나온 드라이브 장착 상태는 sdb와 nvme0n1p2 등 256GB 드라이브 2개인데 아래 df 명령의 결과 나온 내용을 보면 512GB 1개로 보인다.
실제 사용할 때도 이렇게 1개로 보인다.
위에서 보인 명령어만 쓰면 합치기만 하는 것이고 저장된 데이터를 2개의 드라이브에 분산하려면 다음과 같이 balance 명령도 사용해야 한다. 이 명령을 사용하면 저장된 데이터 블록들을 2개의 드라이브에 분산해서 데이터 억세스 속도를 높여주게 된다.
sudo btrfs balance start --full-balance /
이 작업은 시간이 꽤 걸린다.
어마어마한 개선은 아니라도 좋아진 속도를 체감할 정도는 되는 것 같다.
마지막으로 저장된 파일들의 파편화를 제거하기 위해 디스크 조각 모음을 해주면 끝이다.
sudo btrfs filesystem defrag -r /
여기서 -r 옵션은 재귀적으로 하위 디렉토리 속의 파일들도 조각 모음을 하라는 뜻이다. 저장된 파일의 용량이나 갯수에 따라 진행 시간은 다르다.
이제 끝.
WSL을 이용해 이런 저런 실험과 장난을 치다 보면 필연적으로 systemctl 명령을 자주 사용하게 된다.
명령의 옵션이 많은 데 전부 정리하긴 어렵고 자주 쓸만한 것들만 정리한다.
sudo systemctl
sudo systemctl list-unit-files
sudo systemctl is-enabled [서비스 이름]
sudo systemctl is-active [서비스 이름]
sudo systemctl status [서비스 이름]
sudo systemctl enable [서비스 이름]
sudo systemctl disable [서비스 이름]
sudo systemctl start [서비스 이름]
sudo systemctl stop [서비스 이름]
sudo systemctl restart [서비스 이름]
sudo systemctl reload [서비스 이름]
sudo systemctl daemon-reload파일 시스템에 저장된 설정 파일의 변경 사항을 읽고 의존성 트리를 새로 만든다.
Windows에서 Docker Desktop을 사용하는 것은 라이선스가 좀 골 아프다. 그러니 그냥 WSL에 설치한 Docker를 Windows에서도 Docker Client를 이용해 사용해보자.
우선 Docker Client를 Windows 쪽에 설치하자.
https://download.docker.com/win/static/stable/x86_64/
이 위치에 접속하면 Docker 버전 별로 Windows용 Client가 있다. 적당한 파일을 다운로드 받고 압축을 풀어서서 Windows의 Path에 포함된 위치에 저장한다.
Windows에 시스템 환경 변수를 하나 추가한다.
DOCKER_HOST
환경 변수의 값은 아래와 같이 설정한다.
tcp://127.0.0.1:2375설정이 끝나면 아래 그림과 같이 된다.
'시스템 속성' 창에서 '환경 변수(N)...' 버튼을 클릭해서 '환경 변수' 창을 열고 환경 변수를 추가한다. 이 화면에서 Path도 추가할 수 있다.
('시스템 속성' 창은 Windows 메뉴에서 검색하면 바로 나온다)
이제 WSL에서 Docker 설정 파일을 수정한다.
sudo vi /usr/lib/systemd/system/docker.service
내용 중 ExecStart 항목을 수정한다.
[Service]
ExecStart=/usr/bin/dockerd -H fd:// -H tcp://127.0.0.1:2375
이제 WSL에서 Docker를 재시작한 후 Windows Powershell에서 Docker 명령을 실행하면 잘된다. 혹시 restart 대신 설정을 데몬에 즉시 반영하게 하려면 아래와 같이 하면 된다.
sudo systemctl daemon-reload
간혹 reload가 제대로 동작하지 않는 경우가 있기는 하니까 확실하게 하려면 reload 후에 restart까지 해버리는 게 편할 때도 있다.
<같은 회사 AA 분에게 배웠다>