Tag: btrfs

Btrfs Compression(압축) 사용 안하게 설정.

Btrfs 에서 CoW 를 사용 안하게끔 하는 법(NoCoW)은 이미 정리했었다.여기선 Compression 을 사용하게끔 설정된 상황(fstab 에서 compress 설정)하에, 특정 디렉토리에만 압축을 사용하지 않는 방법을 설명한다. 정리 원하는 디렉토리(또는 파일)를 이렇게 설정하면, 새롭게 생성(복사)되는 파일은 압축이 해제된 상태가 된다. 굳이 왜 이런게 필요할까? 여러 상황이 있겠지만, Resilio Sync 를 쓰는 경우에 문제가 될 수 있을 듯

Ubuntu Server: Btrfs Subvolume 사용 설치(NVMe). v2

원 글과 비교하여, 몇가지 내용이 추가되었다. 원 글은 비교를 위해 그냥 남겨두기로 한다. var(@var) – NoCoW 설정 서브볼륨 세분화 /var/lib/dpkg root 로 link(ln -s) 우분투 서버 이미지에는 두가지가 있다. live 가 붙은 것과, 그렇지 않은 것.서버 설치 프로그램면에선 live/비 live 가 확연히 다른데, 정작 설치된 서버 자체는 미묘한 차이만 있는 듯 하다. 아무튼, 이 글은

Snapshot/Snapper: var 디렉토리 처리 문제.

tldr; 세련된 해결책은 아닐 듯 하지만, /var/lib/dpkg 디렉토리를 루트에 포함시키는 방법을 택해봤다. 아직까지 Snapper 를 제대로 쓰고 있진 않지만, 그저 분위기만 보고 있는 상황에선, 예전에 쓴 글 대로 @snapshots 서브볼륨을 따로 만들고 .snapshots 에 마운트해서 사용하는 방법이 제일 좋아 보인다. (이 문장.. 너무 길다.) 또, Btrfs Ubuntu server 에서처럼, 서브볼륨은 Flat 으로 설정(FS Root 아래에

OpenSuse: 왜 서브볼륨 마운트가 필요할까?

** 글을 쓰기 시작할 때만 해도 이 글에 대한 답을 구하지 못했었다. 그런데, 글을 쓰던 중, 답이 보였다. tldr;var, home 등 서브볼륨이 초기 root 디렉토리인 @ 산하에 있음에도 서브볼륨 마운트가 필요한 이유는, Snapper 때문이다.Snapper 가 실행되면서 루트 디렉토리가 수시로 바뀌기 때문에, 최초엔 @ 산하에 있어서 서브볼륨 마운트를 하지 않더라도 같은 결과가 나오지만, 나중엔 반드시 마운트를

Btrfs CoW 확인, NoCoW 설정. (압축은 덤)

Btrfs 파일시스템은 COW(Copy On Write)가 기본값이다.그런데, 자주 변경사항이 발생하는 곳에는 이 CoW 를 쓰지 않는 편이 좋다고 한다.Btrfs SysadminGuide 에 이런 내용이 나와있다. This leads to fragmentation in heavily updated-in-place files like VM images and database stores. Btrfs 를 주 파일시스템으로 사용하는 OpenSuse 를 보면, var 서브볼륨(@/var) 에 NoCoW 를 설정해놓고 있다. (설치 시에 이

Snapper 가 생성한 btrfs subvolume 순차 삭제 (Recursive Deletion)

예를 들어, 아래와 같이 Btrfs Subvolume 이 있다고 가정해본다. 눈에 확 들어오지는 않기 때문에, 위 상황을 아래와 같이 표현해 보도록 한다. @snapshot 이라는 서브볼륨이 있고, 그 아래에 이름이 1,2,3… 인 ‘디렉토리‘들이 있으며, 각각 디렉토리안에 snapshot 으로 명명된 서브볼륨들이 존재한다.toplevel 271(@snapshots) 하에 숫자로된 디렉토리/snapshot 들이 있음을 볼 수 있다. (눈에 잘 안들어와서 그렇지.) 지금 나는, 저

Btrfs 파일시스템 검사. btrfs check.

원문은 이글루스. 여기엔 더 간략하게만 정리했다. 조금 전, 갑자기 파일 서버가 오작동을 일으켰다. 파일시스템이 리드온리로 바뀌고, 재부팅을 해도 그 디스크를 마운트 하지 못하는 현상이 나타났다. 하여, 디스크를 떼어내서 다른 시스템에 연결한 후, btrfs check 를 시행했다.근데? 오류도 나오질 않는데? 왜 그랬던 걸까?검사가 끝난 뒤 다시 연결하니, 언제 그랬냐는 듯 또 잘 된다.거 참. 아무튼, 그때

Btrfs Snapshot, 어떻게 사용하나?

Btrfs Snapshot 에 대한 기초지식에 대해서는, 지난 글에 적당히 정리해놨다.이 글에선, 어떻게 사용하는지에 대해서 역시 ‘적당히’ 정리해보겠다. Btrfs 에 대한 모든 내용은, Btrfs SysAdminGuide 에서 찾을 수 있다. (읽어도 뭔 말인지 잘 감이 안와서 문제지.) Snapshot 은, 간단히 말하면 이런 거다.한 무리의 파일(특정 디렉토리 산하 모든 파일이라 가정..)을 보관해두려 한다. 그런데, 이 파일들 중, 보관해야하는

/etc/fstab 에서 변경한 root 파일시스템이 인식되지 않을 때??

Btrfs Snapshot 공부 중, 또 새로운 사실을 알게 됐다. (아.. 어렵고 어렵구나. 그래도 원인을 파악할 수 있는 기본기(?)가 생겼음에 감사해야할지.) ** 글 끝에 써 있지만, 이 문제를 피하기 위해선 rEFInd 를 사용하는 편이 좋다. 아래 방법은, 꼭 Grub 을 써야만 할 때를 위해 남겨둔다. 아래 글은, Btrfs 의 Subvolume Set Default 기능을, GRUB 과 사용할

꽃삽질 : Snapper, Btrfs snapshot 의 문제점 돌아가기

Snapper 기본 설정의 문제점 파악 Btrfs Snapshot 을 사용하면, 손쉽게 복사본(?)을 만들 수 있다. 완전한 복사본이라 말하기엔 애매한 부분도 있지만, 아무튼 충분히 원하는 효과를 얻을 수는 있다. 문제는, 단순히 ‘보관’을 위한 작업을 위해서는 Snapshot 이 최선의 방법이지만, 만약, 이전 상태로 되돌아가려고 한다면(Rollback), 조금 더 복잡한 방법을 생각해내야 한다는 데에 있다. 이런 필요에서 나온게 Snapper 라는