답변:
phoronix 의 테스트에 따르면 항상 많은 요인에 달려 있습니다. 어떤 경우 에는 SSD에서 큰 파일을 읽을 Btrfs때보 다 훨씬 더 잘 수행됩니다 EXT4. 마찬가지로 디스크 트랜잭션 성능을 고려하면서 Ext4나중보다 성능이 우수합니다.
여기 , 여기 및 여기 (경고 : 긴 기사) 에서 이러한 테스트를 살펴볼 수 있습니다 .
그러나 요약 하자면 , Btrfs 는 SSD 모드에서 사용하더라도 EXT4 파일 시스템에 비해 양적 성능 이점이 없습니다 .
Ext4지금 당장 선택할 수 있습니다 .
2016 년에이 질문에 걸려 넘어지는 사람들을 위해 ... ext4를 사용하십시오. 나는 btrfs를 시도했고 그 차이는 상당하다. 10 일 동안 ext4에 대한 쓰기 IO는 17,800 개 섹터에 달했습니다. Btrfs? 490,400 개의 섹터. 동일한 SSD, 동일한 파일 시스템, 다른 파티션. 기본적으로 동일한 작업량.
드라이브에 쓰기 작업이 없으면 ext4와 btrfs는 모두 "quiet"상태가됩니다. 잘 됐네요
Ext4는 수정 된 데이터와 약간의 오버 헤드를 기록합니다. 오버 헤드는 기록 된 데이터와 관련이 있습니다. 4K 쓰기 (1 블록)는 다음 커밋에서 약 50-80 블록의 오버 헤드를 푸시합니다. (ext4 저널이 완전히 활성화되었습니다)
btrfs에서 단일 4K 블록을 수정하면 다음 커밋에서 4000-5000 개의 오버 헤드 블록을 사용하게됩니다. 기본 커밋은 30 초입니다. 나는 120을 사용했다.
이제는 SSD 사용 방법에 따라 다릅니다. 루트로서 일반적으로 상당히 일정하고 낮은 수준의 쓰기 스트림이 진행됩니다. 로그 파일, ntp 드리프트 파일, man db 재 구축, opensm 토폴로지 업데이트 등 각 이벤트는 다른 4000-5000 쓰기로 btrfs 드라이브를 망치게됩니다.
위의 10 일 숫자는 "쓰기 제한"SSD입니다. 이 17,800 개의 섹터 중 대부분은 작은 시스템 업데이트의 결과였습니다. btrfs 사본 중 하나가 손상되지 않았습니다. 필자의 작가는 정확히 ntp 드리프트, opensm 토폴로지 및 man db 업데이트 (매일)입니다. 시스템 업그레이드 등과 같이 적극적으로 시작된 것을 제외하고는 디스크에 다른 것이 없습니다 vim /etc/whatever.
전체 SSD에서 실제로 많은 쓰기가 발생합니다. 나는 단지 뉴스 매체가 토끼와 무지개를 쫓고 있다는 '쿠즈'를 낭비한다는 점을 볼 수 없습니다. COW에 대해이 가격을 지불하려면 그대로 가십시오. "성능"에 대해서는 그리 많지 않습니다. 그것은 SSD이며 아마도 사람에게 알려진 최악의 "파일 시스템"을 넣을 수 있으며 여전히 거친 힘으로 어느 정도의 성능을 얻을 수 있습니다. Ext4는 사람에게 알려진 최악의 파일 시스템이 아닙니다.
월간 fs 확인이 없습니다. 아래 스크립트를 사용해보십시오. 100 % 해킹이므로 md 마운트 포인트에서 작동하지 않습니다.
#! /bin/bash
dev=`cat /proc/mounts | grep " $1 " | awk '{print $1}'`
x=`basename $dev`
vmnam=`lsblk $dev -o MOUNTPOINT,PKNAME | grep "$1" | awk '{print $2}'`
vmx=`vmstat -d | grep $vmnam | awk '{print $8}'`
lbax=`smartctl -a $dev | grep LBA | awk '{print $10}'`
tmpnam=`mktemp XXX`
echo "Tracking device: $dev, mounted on $1 (vmstat on $vmnam)"
tim=`date +%s`
timx=`date +%s`
while true
do
vm=`vmstat -d | grep "$vmnam" | awk '{print $8}'`
lba=`smartctl -a $dev | grep LBA | awk '{print $10}'`
if [ "$vm" != "$vmx" ]
then
tim=`date +%s`
dif=`dc <<< "$vm $vmx - p"`
lbad=`dc <<< "$lba $lbax - p"`
timd=`dc <<< "$tim $timx - p"`
echo `date` " (sec=$timd) writes=$vm (dif=$dif) (lba=$lbad)"
vmx="$vm"
lbax="$lba"
timx="$tim"
find "$1" -mount -newer "$tmpnam" -print | grep -v "/tmp"
touch "$tmpnam"
fi
sleep 1
done드라이브 자체에 따라 작성된 블록 수와 정확히 어떤 파일이 업데이트되었는지 알려줍니다. 루트 권한이 필요합니다. 직접 참조하십시오. 루트 파일 시스템에서 SSD를 실행하고 스크립트 stat.sh를 호출합니다. 그래서...sudo ./stat.sh /
마지막으로 테스트했을 때 다른 곳에서 듣지 못했지만 ext4 는 솔리드 스테이트 미디어를 먹습니다 . (썸 드라이브, 솔리드 스테이트 드라이브 등) 이러한 장치에서는 사용하지 않는 것이 좋습니다. 대신 ext3을 사용하십시오. SSD의 대부분의 경우 차이점을 알 수 없습니다.
BTRFS는 아직 안정적이지 않습니다. 그러나 중요하지 않은 응용 프로그램에는 충분히 안정적입니다. 부팅 가능한 플래시 드라이브를 만드는 데 사용합니다. 마운트 옵션으로 compress = zlib 및 ssd를 사용하는 경우 압축은 대부분의 솔리드 스테이트 미디어의 쓰기 속도를 낮추고 ssd는 이러한 알고리즘에서 할당 알고리즘을 크게 향상시켜 할당 알고리즘을 변경합니다. 하드웨어에 의한 마모 레벨링 불량. 여전히 문제가되는 성능 영역 중 하나는 동기화 호출이 느리다는 것입니다. 일반적인 사용에는 문제가되지 않지만 dpkg 호출은 모든 작업 후에 동기화되므로 소프트웨어 설치 및 업데이트가 느려질 수 있습니다. BTRFS는 또한 특정 상황에서 매우 유용한 스냅 샷 및 기타 고급 기능을 제공합니다.
BTRFS를 사용하기로 결정한 경우 커널 3.2.0-2 이상을 사용하여 배포판을 사용해야합니다. 필요한 경우 3.1.x를 사용할 수 있습니다. 이전 커널의 경우 최신 BTRFS 모듈을 직접 컴파일해야합니다. 내장 된 것은 거의 안정적이지만, 오류 수정은 이전 버전에서는 작동하지 않으므로 문제가 발생하면 개울을 남길 수 있습니다. 최신 버전에는 가장 일반적인 결함을 실제로 복구 할 수있는 fsck가 있습니다.
마지막 한 가지주의 할 점은 BTRFS 파일 시스템의 스왑 파일이이를 손상 시킨다는보고를 들었습니다. 이 문제는 해결되었을 수도 있지만 구현하기 전에 신중하게 확인하십시오.
BTRFS 설정을 원하는 방식으로 구성하는 데 도움이 필요하면 알려주십시오. 나는 특정 일을 위해 잘 작동하는 몇 가지 미친 것들을했습니다.
나는 일화적인 증거와 ext4가 파일 시스템과 관련된 읽기 및 쓰기 수로 인해 SSD의 수명을 크게 단축시킬 수 있다는 내 경험을 바탕으로 솔리드 스테이트 드라이브에서 ext4를 사용하지 않을 것입니다. 최근에 읽은 한 기사에서는 SSD의 최적화되지 않은 (페이지 크기 등을 고려한) ext4가 디스크 수명을 절반으로 줄일 수 있다고 제안했습니다. 일주일 동안 문제를 해결 한 후,이 문제로 인해 내 SSD가 8 개월간 지속되었다는 결론에 도달했습니다. SSD를 사용하는 경우 파일 시스템이 설정된 일반적인 실린더 크기와 다를 수있는 플래시 페이지 크기와 같은 것을 기반으로 파일 시스템을 최적화하는 방법에 대해 많은 것을 읽으십시오.