원문 보기: https://dawoum.duckdns.org/wiki/GNOME_Display_Manager 그놈 버전 49가 출시되면서, GDM-49가 같이 출시되었습니다. 몇 가지 문제에 부딪힐 수 있습니다. 버전 49.0.1을 설치 후에, 부팅 자체가 완료되지 않고 다른 tty로 접근도 되지 않습니다. 리커버리로 부팅 후에, lightdm으로는 부팅이 됩니다. 이와 관련된 버그는 다음에서 볼 수 있습니다: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/2121017 결론적으로, 오래 전에 설치된 시스템에서 /etc/nsswitch.conf 파일에서 문제가 발생합니다. 따라서, shadow: files systemd와 같이 수정해서 GDM 로긴 화면을 만날 수 있습니다. 다른 문제는 Xsession이 목록화되지만, 해당 세션으로 접근되지 않는다는 것입니다. 게다가, Xsession으로 접근 후에, GDM이 오동작해서 다른 Wayland 세션으로 로그인할 수도 없습니다. 이때, 다른 tty로 접근해서 GDM을 재시작하면 제대로 동작합니다. 만약 Xsession으로 로그인하고 싶을 때에는 lightdm과 같은 다른 로긴 관리기를 사용해야 합니다. 덧, 만약 GDM에서 Xsession으로 정상적으로 로긴하기 위해, GDM 패키지를 다시 컴파일해야 합니다. 데비안 패키지에서 GDM-49.0.1 파일을 받아서 debian/rules 파일에서 -Dgdm-xsession=true 구성 옵션을 추가해야 합니다.
원문 보기: https://dawoum.duckdns.org/wiki/Linux_filesystem_guide
이 기사는 파일 시스템 자체에 대한 내용을 다루려는 것이 아니라, 파일 시스템을 선택하려고 시도할 때 약간의 도움을 제공하는 것이 목적입니다.
많은 리눅스 배포판은 기본 파일 시스템으로 Ext4를 사용하고 있습니다. Ext4는 그 만큼 충분히 강건하고 빠른 파일 시스템입니다.
데스크탑 사용자의 입장에서 파일 시스템을 선택할 때, 2가지 정도를 고려할 필요가 있습니다.
- 갑작스러운 정전 등에서 문제 없이 재부팅이 되느냐?
- 별도로 관리를 해야 하는가?
2021년 말 경, Ext4가 갖지 못한 현대적 기능을 갖춘 Btrfs을 사용하려고 시도했을 때, 포기했던 가장 큰 이유는 강제 재부팅 후에 Ext4와 달리 파일 시스템을 고쳐주지 않아서 부팅이 되지 않는 것에 있었습니다.
반면, ext4는 5년 동안 숫자로 기록해 두지는 않았지만, 강제 재부팅 후에 부팅이 되지 않는 경우가 없었기 때문에, 당시의 Btrfs으로 전환 시도는 느린 속력과 상관 없이 무산되었습니다.
다른 측면에서, 윈도우 파일 시스템은 간혹 조각 모음을 실행해야 하는 경우가 있었습니다. 반면, ext4에서는 단 한번도 조각 모음을 실행한 적이 없습니다.
따라서, 리눅스를 처음 접하는 사용자들은 ext4를 사용하는 것이 바람직해 보입니다.
그럼에도 불구하고, 몇 개의 배포판은 다른 파일 시스템, 예를 들어, Btrfs, XFS, 등을 기본 파일 시스템으로 사용하기도 합니다. 예를 들어, Fedora Linux, OpenSUSE, CachyOS, 등은 기본 파일 시스템으로 Btrfs을 사용하고, Red Hat Enterprise Linux는 XFS를 기본 파일 시스템으로 사용합니다.
고려 사항은 문제인가?
파일 시스템을 바꾸기 전에 몇 가지는 조사해 둘 필요가 있습니다.
갑작스러운 강제 재시작에도 부팅에 문제가 없는가?
위에서 언급한 것처럼, 이전에는 Btrfs에서, 강제 재시작으로 인해 부팅이 되지 않는 경우가 있었지만, 2025년 가상 기계 아래에 설치된 Fedora Linux, CachyOS에서 쓰기 중에 강제 재시작해도 부팅에서 문제가 발생하지 않습니다.
아마도, Btrfs은 바닥부터 작성되고 아직도 활발히 개발되고 있기 때문에, 최신 커널을 사용하는 것이 중요해 보입니다. Fedora Linux는 6.14 커널을 사용 중이고, CachyOS는 6.15 커널을 사용 중입니다.
게다가, 실제 시스템을 Btrfs으로 바꾼 후에, 강제 재시작이 있었고, 문제 없이 재시작되었으며, 커널 6.15를 사용 중입니다.
따라서, 최신 커널을 사용하게 되면, 크게 문제되지 않을 것으로 보입니다.
성능에는 문제가 없는가?
커널 6.15가 출시 되기 직전에, 6.15 버전에서 몇 개의 파일 시스템을 벤치마킹한 기록이 있습니다.
모든 테스트 결과의 기하 평균 값은 아래와 같습니다: (높을 수록 좋습니다)
- XFS : 7047.35
- F2FS : 5884.46
- EXT4 : 5111.56
- Btrfs : 5093.23
- Bachefs :3592.00
여기서, 저장 장치는 2TB Crucial T705 PCIe 5.0 NVMe SSD를 이용했습니다.
결과로서, btrfs이 이제는 ext4와 견줄만한 속력을 보인다는 것과, XFS가 두 파일 시스템에 비해 무려 38% 정도를 앞선다는 것입니다.
따라서, 성능 면에서, btrfs을 사용해도 좋은 시기에 이르렀고, XFS도 충분히 고려해볼 만 합니다.
실제 사용에서, Hard disk drive에서 ext4에 비해, btrfs은 체감할 정도로 느리고, XFS는 더 빠릅니다. Solid-state drive에서는 서로 크게 차이를 느끼지 못합니다.
파일 시스템 관리가 필요한가?
Ext4를 사용했든 지난 몇 년 동안, 저장 장치를 관리해야 하는 경우가 없었습니다.
반면에, XFS는 Systemd 타이머로 scrub를 수행합니다. Btrfs은, Defragmentation, Scrub, Trimming, Balance에 대한 얘기가 있지만, 데스크탑 사용자 입장에서, 특수한 상황 아래에 놓이지 않으면, 대체로 필요가 없어 보입니다.
이와 관련된 내용은 실제 사용 시간이 늘어나면서 확인이 될 것으로 판단됩니다.
왜 다른 파일 시스템을 사용해 보려고 하는가?
Ext4 파일 시스템의 사용에서 문제가 되는 부분은 없었지만, 그냥 재미로 다른 파일 시스템을 사용해 보려고 합니다.
그렇다고 하더라도, 성능 하락이 발생하거나, 많은 관리가 필요하거나 등의 반대 급부가 발생한다면, 굳이 그런 파일 시스템을 사용할 이유는 없습니다. 다행스럽게도, Btrfs은 6.15 커널에서 ext4와 비슷한 성능을 보이고, 당장은 크게 관리의 필요성을 느끼지 못하기 때문에, 심각한 반대 급부는 없다고 보여집니다.
한편, Ext4 파일 시스템에서 조용한 데이터 손상(silent data corruption)이라는 개념이 있습니다. 즉, ext4 파일 시스템에 저장된 데이터가 오류 메시지나 명백한 손상 징후 없이 조용하게 수정되거나 손실되는 상황이 발생할 수 있습니다. 이는 쓰기 작업 중 전력 손실, 지연된 할당, 또는 커널의 버그를 비롯한 다양한 문제로 인해 발생할 수 있다고 알려져 있습니다.
어쨌든, 사용자의 입장에서 다중 백업으로 데이터의 손실을 줄이려고 시도하지만, 이런 식의 원본의 손상은 어떠한 백업 정책으로도 극복할 방법이 없습니다. 이를 해결하기 위해, 정기적으로 체크섬을 시행해서 비교하는 방식과 같은 정책을 시행할 수 있지만, 스크립트를 작성하고, 수행 때에 부하 발생 등을 피할 수 없습니다.
따라서, 그런 상황을 염두에 둘 정도로 중요한 데이터를 갖고 있다면, 해당 기능을 가진 파일 시스템, 예를 들어, Btrfs을 사용하려는 시도는 당연해 보입니다.
이제, 실제 시스템을 ext4에서 다른 파일 시스템으로 전환해 볼 차례입니다.
Actual filesystem conversion information
이미 ext4 파일 시스템을 갖는 시스템은 변환을 통해 btrfs으로 변경할 수 있습니다.
실제에서, hdd는 변환 후에 마운트가 되고 사용할 수 있지만, ssd는 파일 시스템 점검에서 오류가 생기고 마운트가 되지 않습니다. 그 이유를 확인할 수 없었고, 수정이 가능할 것으로 보이지만 수정 후에 역 변환이 되지 않을 수 있기 때문에 수행하지 않았습니다.
또 다른 결과로서, hdd는 ext4에서 btrfs으로 변환 후에, 상당히 느려집니다. 게다가, 조각 모음을 정기적으로 또는 상태를 확인해서 진행해야 하고, 그렇지 않으면 더 느려진다고 알려져 있습니다.
반면에, xfs는 약 2%를 미리 사용하지만, 속력 면에서는 ext4보다 빠릅니다. 예를 들어, 2분 17초 걸리는 컴파일 시간이 1분 58초 정도에 끝납니다.
따라서, Hard disk drive는 XFS를 사용해 볼 필요가 있으며, 아래와 같이 /etc/fstab을 수정할 수 있습니다:
UUID=... Mount_point xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 2
QEMU images directory
Qemu는 이미 COW를 사용하기 때문에, btrfs에서 COW를 사용하지 않도록 변경해야 합니다. 이 이미지를 갖는 파티션은 QEMU, VirtualBox, 및 VMware 이미지만 저장하기 때문에, 속력에 이점이 있는 XFS를 사용해 볼 수 있습니다.
이 파티션은 NVME SSD에 존재하고, xfs로 전환 후에 실제 사용에서 크게 성능 향상을 느끼지 못합니다. 따라서, 나중에 관리에 문제가 발생할 경우에 ext4로의 복귀를 고려해 볼 수 있습니다.
한편, 다른 저장 장치에 이미지를 백업한 후에 다시 복사해 오면, 크기가 상당히 늘어나게 표시됩니다. 원래대로 크기를 줄이기 위해,
- sudo qemu-img convert -O qcow2 cachyos.qcow2 cachyos.qcow3
- sudo mv cachyos.qcow3 cachyos.qcow2
댓글
댓글 쓰기