SD 카드에서 GNU / Linux 용 파일 시스템 선택

SD 카드에서 실행되는 ARM 기반 시스템이 내장되어 있습니다. 현재 ext3을 파일 시스템으로 사용하는 데비안 GNU / 리눅스입니다. 시스템을 다시 설치하려고 할 때 플래시 친화적 인 파일 시스템으로 변경하는 것이 궁금해졌습니다. JFFS2, YAFFS2 및 LogFS에 대해 들어 보았고 모두 작업에 적합하다고 생각합니다. 어느 것을 추천 하시겠습니까? 또한 SSD 디스크에 더 잘 맞도록 많은 ext4 개선 사항이 있다고 들었습니다. ext4를 실행하면 괜찮을 것이라고 해석해야합니까? 이 경우 특히 무엇을 생각해야합니까?

시스템 사용법이 중요하다고 생각합니다. 그러나 일반화를 위해 표준 데스크탑 작업을 수행한다고 가정하십시오 (실제로 작은 ARM 기반 시스템 임에도 불구하고).

답장을 보내 주셔서 감사합니다.

편집 : 위키 백과는 나에게 말한다 (는 "표창장은 필요로했다"문에서) 것을 이동식 플래시 메모리 카드 및 USB 플래시 드라이브가 내장되어 컨트롤러 특정 플래시 파일 시스템의 사용은 어떤 혜택을 추가하지 않도록웨어 레벨링 및 오류 정정을 수행 할 수 . 따라서 나는 ext 파일 시스템을 고수하려고합니다.

플래시 파일 시스템 에 대한 훌륭한 기사 .

플래시 파일 시스템에 관해 말할 때 중요한 질문은 다음과 같습니다. 마모 레벨링이란 무엇입니까? 위키피디아 기사 . 기본적으로 플래시 디스크에서는 블록이 나빠질 때까지 제한된 횟수 만 쓸 수 있습니다. 그 후, 파일 시스템 (SSD의 경우처럼 하드웨어에 내장 된웨어 레벨링 관리가없는 경우)은 해당 블록을 유효하지 않은 것으로 표시하고 더 이상 사용하지 않아야합니다.

일반적인 파일 시스템 (예 : ReiserFS, NTFS, ext3 등)은 그러한 제한이없는 하드 디스크 용으로 설계되었습니다.

JFFS2

압축 및 우아한 마모 레벨링 보호 기능이 포함되어 있습니다.

YAFFS2

• 성공적으로 마운트 해제 후 짧은 마운트 시간 : 차이를 만드는 단일 것.
• 한 번만 쓰기 속성을 구현합니다. 일단 데이터가 한 블록에 쓰여지면 다시 쓸 필요가 없습니다. 마모를 줄이므로 중요합니다.

LogFS

• 아직 성숙하지는 않았지만 이미 리눅스 커널 트리에 포함되어 있습니다.
• JFFS2 / YAFFS2보다 큰 파일 시스템을 문제없이 지원합니다.

UBIFS

• LogFS보다 더 성숙
• 쓰기 캐싱 지원
• 확장 성 : article . 큰 디스크에서는 JFFS2보다 더 나은 성능

ext4

드라이버 나 카드 (예 : SSD 드라이브에 내부 마모 레벨링이있는 경우)가 마모 레벨링을 처리하지 않는 경우 ext4는 플래시 사용에 적합하지 않으므로 최선의 방법이 아닙니다.

어느 것이 최고입니까?

물론 사용 및 지원에 따라 다릅니다. 인터넷에서 읽은 내용에서 UBIFS를 추천합니다. 큰 파일 시스템, 성숙한 개발 단계, 적절한 성능 및 큰 단점이없는 훌륭한 지원.

나는 같은 문제에 직면하고 있었고 약간의 연구도했다. 결국 나는 ext2와 함께 가기로 결정했다.

일부 SDHC 카드는 하드웨어 계층에서 자체 마모 수준을 구현하는 것으로 보입니다. 마모 수준 조정 기능이있는 SDHC 카드를받을 수있는 경우.

웨어 레벨링을 제공하는 파일 시스템은 플래시 레벨웨어 레벨링을 방해하여 실제로 플래시를 사용하는 것이 좋지 않을 수 있습니다. 플래시 레벨 WL 사용). 중요한 데이터를 저장하지 않기 때문에 ext3의 저널링이 필요하지 않기로 결정했으며 보통 어쨌든 정기적으로 백업합니다 (크론).

또한 속도를 높이기 위해 / tmp 및 / var를 tmpfs로 마운트했습니다. 충분한 RAM이 있으면 그렇게해야합니다 (그러나 정기적으로 로그를 회전하거나 삭제하십시오)

힌트 : "noatime"옵션을 사용하여 ext SD 카드를 마운트하십시오

이것이 시스템 프로파일에 맞는지 모르겠지만 읽기 전용 파일 시스템과 읽기 쓰기 파티션 (또는 쉽게 교체 할 수있는 USB 스틱)을 사용하는 것은 어떻습니까? 그렇게하면 OS에 빠른 디스크를 갖게되고 rw 스토리지가 닳 았을 때 쉽게 교체 할 수 있습니다.

그리고 unionfs가 있습니다. 내가 이해 한 것처럼 다른 파일 시스템 (즉, rw fs 위에있는 ro fs)을 "스택"합니다. 읽기 액세스가있는 경우 unionfs는 검색 한 파일이 포함 된 FS에 도달 할 때까지 스택을 검색합니다. unionfs를 작성할 때 스택에서 첫 번째 쓰기 가능 FS를 검색하여 사용합니다.

나는 또한 다음과 같은 흥미로운 기사들을 발견했다 : http://www.linux-mag.com/id/7357/ http://www.linux-mag.com/id/7345/

그리고 SSD 사용에 관한 팁이 담긴 두 기사 : http://danweinreb.org/blog/using-solid-state-disks-on-linux http://www.zdnet.com/blog/perlow/geek-sheet-a- 트위 커-가이드-솔리드 스테이트 드라이브 -ssss-and-linux / 9190

보안뿐만 아니라 사람들이 일반적으로 인식하지 못하는 수많은 다른 이유로 올바른 파일 시스템을 선택하고 크기를 조정하는 것이 무엇보다 중요합니다. 파일 시스템이 없으면 모든 처리가 널 (null)이됩니다.

Olli의 답변을 매우 잘 받아 들였고 OP는 훨씬 오래되었지만 파일 시스템은 내가 머물 수없는 애완 동물입니다. superuser.com은 내가 전에 방문한 것이 아니며 관리자가 아니지만 가입했으며 더 방문 할 예정입니다.

2011 년부터 많은 변화가 있었지만 그때도 USB 카드를 FAT로 포맷하고 USB 드라이브를 사용하여 4Gb + 파일을 운반했습니다. 물론 보안은 호환성이 아니기 때문에 (SD의 S는 많이 사용하지만 7z에서는 암호를 사용합니다) CD ISO보다 큰 것을 가지고 다니지 않았습니다. 대부분 SQL 스크립트와 매일의 시간 차이에 대한 것이 었습니다. 7-Zip에 의해 암호화 된 데이터베이스 스냅 샷이 거의 사망했습니다.

요즘 나는 내가 아는 사람보다 더 빨리 SD를 착용합니다. 고용주의 일부 생산 기계에는 시간 단위로 자동 백업되는 FAT 형식의 USB 스틱이 있습니다. 나는 매일 그것들을 주시하고 있으며, 당신은 짐작으로 종교적으로 백업합니다 (ITAR 물건을 오프라인으로 안전하게 보호합니다). SSD는 일부 경기장을 평준화했지만 여전히 일반 HD만큼 신뢰하지 않으며 SD는 광학보다 나쁩니다. 그들은 순식간에 나 빠지고 손실은 총계입니다.

호스트 OS에 무작위로 쓰도록 초대하는 모든 파일 시스템 (NTFS, 휴지통)은 SD에 나쁜 소식입니다. 또한 마운트를 해제하면 많은 도움이되며 OS가 마운트 해제 된 스토리지에 액세스하려고 시도하지 않으므로 SD에 자체를 끄는 스크립트 (모든 SD의 표준 파일 중 하나)가 포함되어있는 한 모든 파일 시스템이 수행합니다.

SD를 읽는 것은 오늘날에도 여전히 느리기 때문에 파일 단위 대신 미러링 할 때 디스크 이미지 (dd)와 같이 전체 이미지를 가져 오는 것이 좋습니다. dd는 또한 문제가있을 때 알려 주므로 파일 관리자가 kaboom으로 이동하지 않습니다.

물론, 주된 목적이 페니-스톡의 수명을 연장하는 것이라면 사업에 대해 잘못된 길을 가고 있습니다. 나는 SD의 수명을 연장하기 위해하지 않고 내가 보지 않을 때 SD가 나빠지는 것을 막기 위해 노력합니다. 차이가 있습니다.

나는 ext4 또는 SD에 대한 저널링 FS를 피합니다. 왜냐하면 나는 그들이 나쁜 글을 쓸 때 신경 쓰지 않기 때문입니다. 그러나 하루가 지나면 읽을 수 없을 때 확실히 아파요!

fat (32?)를 사용하라는 권장 사항에 대한 응답으로 : 성능 테스트를 수행 한 결과 fat32가 파일을 작성할 시간이 매우 예측 가능하다는 것을 알았습니다 (2GB는 1GB + 오프셋의 두 번 필요, 3GB는 트리 시간이 필요함). 1GB + 오프셋). ext4의 성능은 ext3보다 약간 우수합니다. ext3과 ext4는 빠르지 만 때로는 저널 파일을 디스크에 쓰는 데 약간의 시간이 더 필요합니다 (선형 쓰기 시간 동작 없음). 모든 테스트는 파일이 실제로 디스크에 기록되는지 확인하기 위해 fsync ()로 수행되었습니다. sync ()로 몇 가지 테스트를 수행했습니다. 쓰기 성능이 매우 떨어집니다. 그래서 나는 fsync ()로 돌아갔다. fsync ()가 충분한 지 확인했습니다. 따라서 시스템을 종료하지 않고 장치의 전원을 켜거나 마운트 해제하지 않고 SD 카드를 제거했습니다. 어떠한 경우에도 작성된 파일 또는 디렉토리 구조가 손상되지 않았습니다.

감사합니다, 토마스

손실이없는 SD 카드를 원한다면 BTRFS다음과 같은 이유로 사용하는 것이 좋습니다 .

BTRFS 2007 년 Oracle에서 처음 생성 한 EXT와 비교 한 새로운 파일 시스템입니다.

기존 파일 시스템에 새로운 기능을 제공합니다.

• 클로닝 / 스냅 샷
• Diffs (송수신)
• 할당량
• 노동 조합
• 자체 치유 (커밋 기간 기본값은 30 초)

추가 설명 및 비교는 이 pdf를 참조하십시오.

새로운 비교를 위해이 사이트를 참조하십시오