LVM cache 사용하기

참고: Logical Volume Manager의 cache 기능은 아직 커널에서 위험한 기능으로 되어있다. writeback 모드를 사용하면 데이터 손실 가능성이 크고 writethrough 모드를 사용하면 바로바로 디스크에도 기록하기때문에 추가적으로 발생하는 데이터 손실은 없는것으로 보인다.

아래 내용은 대부분 이곳에서 가져온 글이며, 개인적으로 좀 더 편리하게 찾기위해 하는 포스팅이다.

1. 캐시용 미디어 초기화 (sdc가 캐시용 미디어 일 경우를 기준)
parted /dev/sdc
– mklabel gpt (or mklabel msdos)
– mkpart ext2 1M 100%
– set 1 lvm on
– quit

2. 볼륨 그룹 확장 및 캐쉬용 볼륨 생성 (기존의 VG는 lv 일 경우를 기준)
pvcreate /dev/sdc1
vgextend lv /dev/sdc1

lvcreate -L 2G -n lv_cache lv /dev/sdc1 (lv_cache 볼륨을 /dev/sdc1 미디어만 사용하도록 지정하여 생성)
lvcreate -L 12M -n lv_cache_meta lv /dev/sdc1 (lv_cache_meta 볼륨을 /dev/sdc1 미디어만 사용하도록 지정하여 생성, metadata는 최소 8MiB 필요, metadata 영역없이 cache pool을 생성하면 data의 1000배 적은 용량으로 자동 생성된다.)

lvconvert –type cache-pool –cachemode writethrough –poolmetadata lv/lv_cache_meta lv/lv_cache

3. 기존의 볼륨에 캐시 할당
lvconvert –type cache –cachepool lv/lv_cache lv/home (기존의 home이라는 볼륨에 캐시 할당)

4. 캐시 할당 제거
lvconvert –uncache lv/home (cache pool도 함께 지워진다.)
lvconvert –splitcache lv/home (cache pool은 유지된다.)

5. 기타
물리장치가 고장나거나 사라지면 아래처럼 [unknown]으로 표시되며 경고 메시지가 출력된다.

$ pvs
WARNING: Device for PV qxYE8y-ale2-QPxN-tN01-8k3W-HgL3-29l1RR not found or rejected by a filter.
PV VG Fmt Attr PSize PFree
/dev/vdb1 vg lvm2 a-- 12.00g 0
[unknown] vg lvm2 a-m 1.89g 1.89g

이런 경우는 vgreduce –removemissing –force vg 와같이 명령을 실행하면 강제로 제거할 수 있다.

GDM이 실행 안되는 문제

Gentoo 리눅스를 설치한 LettePanda에서 갑자기 systemctl start gdm이 안되더라…

중간에 무슨 일이 있었는지 모르겠지만 아래와같은 메시지가 나타났다.

Jan 18 21:15:38 lattepanda gdm-launch-environment][7364]: pam_systemd(gdm-launch-environment:session): Unknown parameter 'kill-session-processes=1', ignoring
Jan 18 21:15:38 lattepanda systemd[1]: Created slice User Slice of UID 115.
Jan 18 21:15:38 lattepanda systemd[1]: Started /run/user/115 mount wrapper.
Jan 18 21:15:38 lattepanda systemd[1]: Starting User Manager for UID 115...
Jan 18 21:15:38 lattepanda systemd-logind[230]: New session c505 of user gdm.
Jan 18 21:15:38 lattepanda systemd[1]: Started Session c505 of user gdm.
Jan 18 21:15:38 lattepanda systemd[7369]: pam_unix(systemd-user:session): session opened for user gdm by (uid=0)
Jan 18 21:15:38 lattepanda systemd[7369]: Reached target Timers.
Jan 18 21:15:38 lattepanda systemd[7369]: Reached target Sockets.
Jan 18 21:15:38 lattepanda systemd[7369]: Reached target Paths.
Jan 18 21:15:38 lattepanda systemd[7369]: Reached target Basic System.
Jan 18 21:15:38 lattepanda systemd[7369]: Reached target Default.
Jan 18 21:15:38 lattepanda systemd[7369]: Startup finished in 97ms.
Jan 18 21:15:38 lattepanda systemd[1]: Started User Manager for UID 115.
Jan 18 21:15:38 lattepanda /usr/libexec/gdm-x-session[7374]: (EE)
Jan 18 21:15:38 lattepanda /usr/libexec/gdm-x-session[7374]: Fatal server error:
Jan 18 21:15:38 lattepanda /usr/libexec/gdm-x-session[7374]: (EE) Cannot open log file "/var/lib/gdm/.local/share/xorg/Xorg.pid-7376.log"
Jan 18 21:15:38 lattepanda /usr/libexec/gdm-x-session[7374]: (EE)
Jan 18 21:15:38 lattepanda /usr/libexec/gdm-x-session[7374]: Please consult the The X.Org Foundation support
Jan 18 21:15:38 lattepanda /usr/libexec/gdm-x-session[7374]:          at http://wiki.x.org
Jan 18 21:15:38 lattepanda /usr/libexec/gdm-x-session[7374]:  for help.
Jan 18 21:15:38 lattepanda /usr/libexec/gdm-x-session[7374]: (EE)
Jan 18 21:15:38 lattepanda /usr/libexec/gdm-x-session[7374]: Unable to run X server
Jan 18 21:15:38 lattepanda systemd-logind[230]: Session c505 logged out. Waiting for processes to exit.
Jan 18 21:15:38 lattepanda systemd-logind[230]: Removed session c505.
Jan 18 21:15:38 lattepanda systemd[1]: user-runtime-dir@115.service: Unit not needed anymore. Stopping.
Jan 18 21:15:38 lattepanda systemd[1]: Stopping User Manager for UID 115...
Jan 18 21:15:38 lattepanda systemd[7369]: Stopped target Default.
Jan 18 21:15:38 lattepanda systemd[7369]: Stopped target Basic System.
Jan 18 21:15:38 lattepanda systemd[7369]: Stopped target Timers.
Jan 18 21:15:38 lattepanda systemd[7369]: Stopped target Sockets.
Jan 18 21:15:38 lattepanda systemd[7369]: Stopped target Paths.
Jan 18 21:15:38 lattepanda systemd[7369]: Reached target Shutdown.
Jan 18 21:15:38 lattepanda systemd[7369]: Starting Exit the Session...
Jan 18 21:15:38 lattepanda gdm[269]: Could not start command '/usr/libexec/gdm-session-worker': Too many open files
Jan 18 21:15:38 lattepanda gdm[269]: GLib: g_child_watch_add_full: assertion 'pid > 0' failed
Jan 18 21:15:38 lattepanda gdm[269]: Child process -7374 was already dead.
Jan 18 21:15:38 lattepanda gdm[269]: Child process 7364 was already dead.
Jan 18 21:15:38 lattepanda gdm[269]: Unable to kill session worker process

Could not start command ‘/usr/libexec/gdm-session-worker’: Too many open files 이걸 마지막으로 그 위 라인들이 반복해서 나타나는것이 사라지고 잠잠해진다. 구글링 해보니 이 페이지가 나왔다. 처음엔 그냥 ls만 해봐서 문제 없는데? 싶었다. 하지만 ls -al 하니 아래와같이 root.root로 .local 파일의 권한이 할당되어있는데… 무슨 문제가 있었길레 뜬금없이 갑자기 이렇게 되버린건지 모르겠다. 암튼 chown -R gdm.gdm .local 그리고 다른 파일도 권한을 바꿔서 잘 되었다.

lattepanda /var/lib/gdm # ls -al
total 4
drwxr-xr-x 1 gdm  gdm   108 Jan 15 15:55 .
drwxr-xr-x 1 root root  374 Jan  1 19:05 ..
drwxr-xr-x 1 gdm  gdm    84 Sep 19 19:53 .cache
drwxr-xr-x 1 gdm  gdm    64 Sep 15 03:08 .config
-rw------- 1 gdm  gdm  1678 Oct  2 09:41 .ICEauthority
-rw-r--r-- 1 root root    0 Jan 15 15:55 .keep_gnome-base_gdm-0
drwxr-xr-x 1 root root   10 Sep  4 01:01 .local
lattepanda /var/lib/gdm #

그런데 로그파일을 못열었다고 gdm이 실행안되는건… 바람직한걸까?

직접 빌드한 리눅스 커널의 모듈 사이즈가 클 경우 해결 법(?)

최근 우분투 커널 설정과 동일한 설정으로 커널을 빌드하여 모듈의 용량을 본 적이 있었다. 무려 2기가 넘는 용량에 놀랐었는데… 쓰이지 않는 모듈 최대한 빼고 빌드하여도 수백메가 넘는 용량을 보였다. 그냥 데스크톱에서 사용 할 목적이면 신경도 안썼겠지만 우분투 리눅스의 모듈은 이보다 훨씬 적은 용량이였고 제한 된 스토리지 용량에 올리려다보니 계속 신경이 쓰여 구글링을 해보았다.

먼저 답을 얻은 글: https://groups.google.com/forum/#!topic/comp.os.linux.development.system/bjU7AfeZl5I

방법은 두가지이며 무엇을 선택하더라도 결과적으로 동일한 용량을 가지게된다.

1. make INSTALL_MOD_STRIP=1 modules_install
2. CONFIG_DEBUG_INFO 제거

두번째 방법은 아래 설정에서 해제하면 된다.

디버그 정보를 포함 하였을 때 용량

디버그 정보를 제거 하였을 때 용량

꽤나 큰 차이를 보인다. 디버그 정보가 있어도 이걸 활용하거나 직접 고칠일은 없으므로 용량이 넉넉하지않은 타겟의 커널을 빌드할 때 신경을 써야겠다.

btrfs + samba + shadow_copy2로 home 폴더에 이전버전 활성화하기

파일을 변조하는 악성코드가 돌아다닐 때 구글링하여 정보를 모은 후 구축했던 내용. 나중에 포맷등에 의한 새로 환경을 세팅할 때 참고하기위해 기록.

공유를 위한 파티션을 하나 만들고 btrfs로 포맷, 그리고 /opt/smbshare 폴더를 생성, 마운트한다. 이후 해당 경로에 .snapshots 폴더를 만든다.

아래 내용은 btrfs 파티션을 /opt/smbshare에 마운트 한 상황을 기준으로 기술하였다. samba의 홈 폴더를 별도로 두어 samba의 사용자 폴더는 리눅스 쉘에서의 사용자 폴더와 구분되도록 하였다. (history등 상태나 설정파일들을 공유폴더에서 나타나지 않도록 하기위함.)

/etc/samba/smb.conf 파일 중 home 섹션을 아래와같이 vfs와 shadow내용을 추가하고 path 내용을 btrfs 파일시스템의 경로로 설정한다. 나머지는 CentOS의 samba 기본 설정.

[homes]
        comment = Home Directories
        path = /opt/smbshare/%S
        valid users = %S, %D%w%S
        browseable = No
        read only = No
        inherit acls = Yes

        vfs objects = shadow_copy2
        shadow:basedir = /opt/smbshare
        shadow:snapdir = /opt/smbshare/.snapshots

이제 주기적으로 쉐도우 복사본을 만드는 스크립트를 작성하면 된다. 아래는 현재 사용중인 스크립트이며 경로는 /opt/smbshare/mksnap.sh 로 저장했다.

#!/bin/sh
/usr/sbin/btrfs sub snap -r /opt/smbshare /opt/smbshare/.snapshots/@GMT-`date -u +%Y.%m.%d-%H.%M.%S`

GMT 시긴대 기준으로 .snapshots 폴더아래에 읽기전용 스냅샷을 생성한다(KST 기준으로 만들고싶었지만 samba 설정에서 KST 시간대로 인식하는 설정법을 찾지 못하였다.).
덧) 일정기간 이후의 스냅샷을 지우는 스크립트는 따로 만들어두지않았다. 종종 용량을 체크하여 직접 지울 계획이다. 스냅샷을 지우는 명령은 btrfs sub delete [폴더명]이다.

이제 cron에 root 계정으로 등록한다.

0 * * * * /opt/smbshare/mksnap.sh

용량이 남아도는 관계로 매 시간마다 스냅샷을 생성하고있다(…). 만약 특정개수 이상 생성 안되도록 하려면 이곳(github)이곳(github)이곳(github)에 올린 코드를 활용하거나 구하면 될듯하다. (표준시간대 기준으로 생성하지않으므로 코드 수정이 필요.)

이렇게 하면 공유폴더에서 등록정보를 열고 ‘이전 버전’을 확인하면 아래와같이 매 시간마다 생성된 스냅샷 내용을 열 수 있다.

이제 파일 히스토리나 백업 프로그램의 백업 대상을 공유폴더에 지정해두면 리눅스 머신이 털리지 않는이상 파일을 안전하게 보관가능하다. 또한 실수로 파일을 지웠을경우, 이전에 작업한 파일내용을 열어야 할 경우에도 활용가능하다.

만약 SELinux를 사용중이라면 사용자 폴더를 생성 후 ls -Z 명령으로 보안권한을 확인 해 봐야한다.

drwx------. iruis users unconfined_u:object_r:samba_share_t:s0 iruis

이런식으로 samba_share_t 권한이 없다면 chcon -t samba_share_t -R [폴더명] 같이 실행하여 samba 서비스의 접근을 허용해야 파일을 읽을 수 있다. (-R 옵션은 하위폴더 포함하여 모두 권한을 변경한다.)

결론: btrfs 좋다. (응?)

systemd를 사용하는 리눅스 파일 시스템을 다른 머신으로 복사할 때 주의 점

사용중인 리눅스 머신의 파일시스템을 다른 머신에서 그대로 사용하기위해 rsync -aXHv –numeric-ids /source/ /target/ 과같이 1:1복사하여 두 머신을 켰을 경우 두 머신이 동일한 IP를 받게되었다.

dhcp 클라이언트가 mac address가 아닌 다른 방식으로 아이피를 얻어오는것같다. 구글링에서 IP를 다시 얻는 방법은 다들 systemd-networkd를 재시작하는 정도와 다른 방법도 있었지만 이게 먹혀들지않았다. /run/systemd/netif/leases 내 생성되어있는 파일을 지워보라는 방법 또한 안먹혔다. 혹시나 파일 내 clientid 값이 둘 다 같은것이 원인인가했지만 이걸 다시 생성하는 방법도 안나오고 hostname이 동일해서 그런지 확인하는 중 hostnamectl 명령을 실행하여 확인이 가능한 machine id 값이 동일한것에서 설마 하였다.

buildroot에서 systemd를 사용하게 되면 간혹 systemd-machine-id-setup 명령을 실행해야 하는 경우가 있어 이미 생성 된 /etc/machine-id 파일을 지우고 명령을 실행하니… 바로는 안되었고 재부팅을 하니까 복사된 파일시스템을 사용하는 머신은 새로운 IP를 받게되었다.

덕분에 이번에도 한시간 넘게 시간을 낭비했다(…)