저널링 파일시스템 선택하기
글쓴이: weirdo96 / 작성시간: 금, 2002/07/05 - 2:26오전
현재의 하드디스크는 정말로 용량이 엄청나게 커졌습니다. 물론 이것을 매우 자잘한 조각으로 나누어 쓰실 수도 있겠지만, 관리의 어려움과 취급되어지는 파일의 크기를 고려한다면 40G정도의 한 덩어리 파티션을 만들어 쓰게 되기 쉬운데요. 이것을 ext2라는 것으로 쓰게 될때 만나게 될 부팅시 걸리는 시간 등등.... 필연적으로 요즘은 저널링 파일시스템을 고려하지 않을 수 없는 것 같습니다. 이때 우리가 어떤 것을 선택해야 할까요? 물론 이것은 글쓰는 이가 게을러 어디가를 뒤져 보면 답이 있을 질문을 올리는 것이겠지만 ...
자! 당신이라면 4가지나 되는 저널링 파일시스템중 무엇을 선택하고, 그 이유는 무엇입니까?
댓글
저널링 파일시스템은 처음 reiserfs를 써봤습니다. 그 당시는 다른걸
저널링 파일시스템은 처음 reiserfs를 써봤습니다. 그 당시는 다른걸 선택할 수 없었기에 reiserfs만 쓰다가 ext3를 잠깐 써보고 작년에 jfs하고 xfs를 써봤습니다. 80, 30, 20기가 하드를 lvm으로 묶었는데 jfs버그때문에 50기가 가량이 날라가서 xfs로 바꿨습니다. 그 이후에는 jfs를 사용하지 않아서 성능이나 기능면에서는 잘 모르겠네요. jfs의 경우에는 작은 버전업을 자주하는데
가끔 치명적인 버그가 있습니다. 그래도 버그패치는 금방되는편입니다.
xfs로 아무 문제없이 잘 쓰다가 문제가 생겼는데 그건 파일시스템의 크기를
늘릴 수 있어도 줄일 수 없다는거였습니다. lvm특성상 파일시스템의 크기를 줄이면 뒤에달린 하드를 떼어낼 수 있는데 파일시스템자체에서 지원하지 않으니 난감하더군요. 결국 다른시스템에 백업하고 ext3로 밀고 아직까지 사용중입니다.
reiserfs는 일반적인 상황에서 무난히 쓸 수 있을것 같습니다. 작은파일들이
많은 시스템에서 뛰어는 성능을 보이고요. 커널버전과 궁합이 잘 맞는 버전이라면 별 문제는 없을것 같습니다.
jfs는 앞에서와 같은 이유로 별라 안써봐서 잘 모르겠지만 일반적으로 대용량 파일처리가 필요한 시스템에 사용되어질거라 생각됩니다. 하지만 아직 구현되지않은 기능이 많아서 현재시점에서 도입하는건 무리라고 생각되어집니다.
xfs는 제 경험과 주위사람들이 얘기하는걸 봤을때 상당히 안정적인것 같습니다. jfs와 함께 대용량 시스템에서 사용되어질 수 있고요. 다만 lvm을 사용할때와 같은 특수한 상황에서 필요한 파일시스템의 크기를 줄일 수 없다는 단점이 있습니다. 최신 버전에서는 어떤지는 잘 모르겠네요.
ext3는 아직 1.0버전도 안나왔지만 일반적으로 사용하는데는 문제가 없어보입니다. 서버의 대부분을 ext3를 지원하게 했는데 아직까지 별다른 문제점은 없습니다. 특히 ext2에서 데이터 삭제없이 ext3로 변환가능하고 ext2로도 마운트된다는점은 큰장정이 될 수 있을것 같습니다. ext2에 저널을 추가했기에 가능한일이겠죠.
일반적인 사용에서라면 어떤걸 사용하더라도 별 무리는 없을것 같습니다. 다만 저널링이외에 NFS, QUOTA같은걸 잘 지원하는지 살펴봐야겠습니다. 호환성을 고려한다면 ext3밖에 대안이 없을것 같고 대용량에서는 jfs, xfs가 좋을듯 싶고 작은파일이 많은곳은 reiserfs가 좋을것 같습니다. 뭐 골라먹는 재미라고나 할까...
참고로 BSD의 예를 들면 그쪽은 예전의저널링 파일시스템인 LFS가
참고로 BSD의 예를 들면 그쪽은 예전의
저널링 파일시스템인 LFS가 있습니다만
NetBSD를 제외하고는 빌드조차 안되는 상황이고,
BSD의 기본 파일시스템인 FFS에는 저널링과
유사하지만 조금 다른 방식을 취하고 있습니다.
Softupdate는 메타데이터간의 의존성 순서를
유지하며 디스크에 쓰는 관계로 비동기 쓰기에서도
일정 수준의 안정성을 보장하고, FreeBSD
5.0-current의 경우 시작할 때 체크해야 하는
파일시스템이 있을때 일단 마운트하고,
fsck는 그 순간의 스냅샷 기준으로 백그라운드에서
돌게 됩니다. 아무리 마운트할 디스크가 커도
바로 시스템은 시동하고... 나중에 fsck는
알아서 디스크 검사 다 한 다음에
조용히 자기 일을 마칩니다. 물론 그 동안에도
해당 파티션은 제대로 동작하고요.
최신 FFS의 이런 특징 때문에 BSD에는 XFS나
JFS의 장점이 많이 반감되는데... 나중이라도
포팅이 되어서 직접 성능을 비교해 볼 수
있으면 좋겠네요.
엄밀히 말해서 백그라운드 fsck가 저널링은 아니죠. 다만 fsck가 오
엄밀히 말해서 백그라운드 fsck가 저널링은 아니죠. 다만 fsck가 오래 걸리는 단점을 약간 극복하자는 의도구요.
진정한 저널링은 아예 백그라운드로 fsck돌릴 필요도 없이 순식간에 checking끝나죠. 저널링의 단점 반감이 아니라 저널링이 없으니 저렇게라도 해야겠죠.
또 FreeBSD 5.0 버젼이 아직 나온것도 아니구요. :-)
JFS는 IBM사이트에서 읽어보니 GPL라이센스라서 BSD에서 쓰지는 못할 것 같습니다. IBM말로는 BSD라이센스 적용할 계획은 없는것 같더군요. XFS도 마찬가지구요. 결국 BSD는 독자적으로 저널링 파일 시스템을 구축해야할 것 같습니다.
사용자 관점에서 저널링 파일시스템의 잇점이란- 크래시 이후 복구
사용자 관점에서 저널링 파일시스템의 잇점이란
- 크래시 이후 복구 속도 빠름
- 성능 향상
정도입니다만 FFS+SU+background fsck는 이 문제를 해결합니다.
저널링의 경우 순식간에 checking이 끝난다는 것은 log replay를
의미하는 것인데, log replay를 하고 시작하든 미리 시작하고
나중에 체크하든 것이나 별반 다를게 없다는 것이죠.
즉 같은 문제를 해결하는 방법이 하나만(저널링)만 있다는 것은
아닙니다. 이런 문제라면 BSD LFS가 가장 이상적이지만 아직 연구실
신세이죠. 리눅스용 LFS 프로젝트도 있는 것으로 압니다.
p.s. XFS든 JFS든 라이센스는 문제가 되지 않습니다. FreeBSD 컴파일러
시스템은 gcc + binutils입니다. :)
p.s. 5.0은 쓰시고 싶으면 지금이라도 개발 버전 받아보시면 됩니다.
background fsck는 이미 적용된지 1년이 넘었고 충분히 안정적입니다.
요즘에는 커널 스레드 때문에 조금 불안하지만...
--
익스펙토 페트로눔
GPL 이랑 BSD에서 쓰고 못쓰고는 상관이 없습니다.
GPL 이랑 BSD에서 쓰고 못쓰고는 상관이 없습니다.
GPL이던 BSD던 라이센스가 무슨 상관이야, 자기만 잘쓰고 남에게 피에
GPL이던 BSD던 라이센스가 무슨 상관이야, 자기만 잘쓰고 남에게 피에는 주지 말아야지 이 양심업ㅂ는 인간들아
FreeBSD KR에 있는 그 글을 읽은 리눅서들은 FreeBSD에 호감
FreeBSD KR에 있는 그 글을 읽은 리눅서들은 FreeBSD에 호감이 생기기는 커녕 반감만 생깁니다. 특히 그 컬럼중에 하나는 정말 과격합니다. :-)
그리고 FreeBSD KR홈페이지에 있는 그 오래된 리눅스 vs. Fre
그리고 FreeBSD KR홈페이지에 있는 그 오래된 리눅스 vs. FreeBSD에 대한 컬럼은 좀 고려해보시는건 어떨까요? 그 글 자체의 편협성(상당부분 편협함 혹은 극단적이고 감정적인 논지)은 언급하지 않더라도, 1999년도에 쓴글이 아직도 유의미합니까? 윈도우도 2000 나온지 언제인데 아직도 NT 4.0을 기준으로 쓴 자료를...
전 Linux vs *BSD나 Linux vs NT/2000/XP 에서
전 Linux vs *BSD나 Linux vs NT/2000/XP 에서
극단적이고 편협하며 감정적인 견해를 너무나 많이
접했기 때문에(심지어 이번달 컴퓨터 잡지에도 있더군요)
그정도는 약과라고 봅니다.
거긴 원래 BSD칭찬하고 많이 쓰라고 만든 홈페이지 아닙니까? :)
세상에 널린게 리눅스 좋다는 홈페이지인데
그런데도 좀 있도록 해 주십시오.
글이 오래되어서 좀 낡은 정보라는 점에 대해서는
충분히 의미있는 말씀이라 생각합니다. 단 원본 쓴
사람이 글을 업데이트하지 않고 있고, 맘대로 고치는 것도 좀 그렇고,
politically correct하게 쓸 엄두도 나지
않는지라 그냥 두고 있습니다.
적절하게 업데이트하기 보다는 새로
쓰는편이 더 낫겠다는 생각은 하고
있습니다.
--
익스펙토 페트로눔
네 이해합니다 다만 조금 객관적이고 이성적인 설득이었으면 좋았을꺼라고 생
네 이해합니다 다만 조금 객관적이고 이성적인 설득이었으면 좋았을꺼라고 생각합니다.
저 쪽에서 편협하고 감정적으로 나온다고 해서 저희도 그럴 필요는 없다고 보거든요.
사실 어떻게 보면 리눅스도 BSD덕을 음으로 양으로 많이본 사촌지간인데...
GPL코드를 BSD커널에 넣지는 않는것으로 압니다.만약 그랬다간 라이
GPL코드를 BSD커널에 넣지는 않는것으로 압니다.
만약 그랬다간 라이센스 자체를 고쳐야겠지요. 컴파일러가 GCC인것과는 다른 문제라고 봅니다. BSD라이센스인 커널에 GPL코드를 넣으면 그건 BSD라이센스를 따를 수 있을까요? 아니면 파일시스템은 GPL로 하고 기타 커널 부분은 BSD라이센스로 하는 듀얼 라이센스로 해야할까요?
또 XFS나 JFS는 보시면 아시겠지만 단순히 저널링만을 의미하지 않습니다.
어머어마하게 없어진 limit 제한... 대용량 파일 처리에 적합한 오랫동안 검증된 차세대 64-bit 파일 시스템
이런 기능들은 리눅스의 엔터프라이즈 시장 진입에 커다란 역할을 해내고 있습니다.
그리고 이미 나와서 검증되고 안정화된 파일 시스템을 놔두고, 아직 개발중인 BSD 5.0버젼을 production환경에 쓸 수 있다고 자신하십니까?
커널 쓰레드 문제나 SMP성능 개선도 5.0에서나 확보되는거 아닙니까?
개인적으로 FreeBSD 5.0에 기대가 큽니다. 그러나 아직은 리눅스 커널 2.4를 선택할겁니다. 성능면에서 더 나으니까요. 아파치 2.0 이나 자바, DBMS등이 점점 멀티쓰레드에 의존하는 상황에서, Userland thread로 다중 프로세서의 잇점을 제대로 활용할 수 없습니다. 그래서 FreeBSD도 커널모드 쓰레드를 준비하고 Next Generation SMP등에 신경쓰는거 아닐까요?
- BSD커널에 GNU코드도 있습니다. FPU에뮬레이션이나일부 사운드
- BSD커널에 GNU코드도 있습니다. FPU에뮬레이션이나
일부 사운드 드라이버 등이 있습니다. 하지만 소스
레벨에서 분리가 되어 있고 없어도 지장 없을 뿐이죠.
가령 ext2fs 지원은 GPL이기 때문에 기본 커널에는
없습니다. 자신이 선택해서 컴파일하는 것은 자유입니다.
현재의 BSD vnode 시스템상 ext2의 예가 그랬듯이
xfs나 jfs를 추가하는 것은 얼마든지 가능합니다.
단 기본 커널에 넣지는 않겠죠.
- XFS나 JFS의 대용량 처리 특징은 저널링과는 관련이
없습니다. 그건 그 파일시스템의 고유한 기능이지
저널링 처리를 위해 꼭 필요한 기능은 아닙니다.
(이글의 주제는 저널링 파일시스템에 대한 이야기이지
대용량 엔터프라이즈 시스템에 대한 이야기는 아닙니다.
물론 저널링이 그러한 특징에 포함될 수는 있습니다)
또한 파일 크기 제한 등을 해결하려면 파일시스템 뿐
아니라 관련 시스템 콜, 라이브러리에 모두 관련되는
이야기입니다. 또한 저널링과는 관계 없는 이야기입니다.
- XFS나 JFS는 리눅스 이외의 OS에서 나왔고 오랫동안의 실제 경험은 AIX나 IRIX에서의 이야기이지
리눅스에서의 이야기는 아니라 생각합니다. 아래에도
Reiserfs를 포함해서 불안정성에 대한 이야기도 몇
있었고요. ext2fs가 그랬듯 향후 1-2년은 지나고
나서 어느 쪽이 살아남는지가 결과를 좌우할 것이라
봅니다.
--
익스펙토 페트로눔
아! 그리고 성능 이야기를 꺼낸것은 이미 리눅스는 저널링 파일시스템이 대
아! 그리고 성능 이야기를 꺼낸것은 이미 리눅스는 저널링 파일시스템이 대세고, 서로 충분한 정도의 저널링 기능을 가지고 있으며, 이제는 성능이나 장단점을 비교해서 선택해서 써야하는 단계라는 의미에서 이야기를 꺼내봤습니다.
원래 포스팅하신 분도 과연 이들 파일시스템의 차이점이 무엇이고 어느 것이 나의 상황에 맞고 성능이 우수한가에 대해서 여쭤보신것이지 저널링 자체는 이미 너무 기본적인 기능이 되버려서 별다른 논의의 대상이 되지 못한다고 봅니다.
http://www.xfs.org/xfs_users.html안정성
http://www.xfs.org/xfs_users.html
안정성에 대해서는 이 정도면 충분한 답변이 되리라 봅니다.
그리고 영원히 어느 하나가 시장을 다 먹어버리지는 않을지도 모르죠.
사이좋게 Ext3, ReiserFS, JFS, XFS가 공존할지도요. 왜냐하면 이들 사이에 특징이나 용도가 많이 다르거든요.
갑자기 저널링 파일 시스템이 없는 FreeBSD이야기를 꺼내셔서 그것도 개발 버젼에서의 background fsck 라니... :-)
논점이 많이 빗나가네요. 서로간에... 엄밀히말하면 background fsck도 저널링이랑은 상관 없는 이야기입니다. 다만 FreeBSD에서는 이런식으로 해결한다는 것 보여줄 수는 있죠... (물론 충분히 가치 있는 정보였습니다. 저도 그런 기능은 처음 들었거든요. 저널링만 있는줄 알았는데 다른 방법도 있다는 사실을...)
하여간 뭐 프비 5.0도 기대됩니다. 많은 발전이 있을거라고 봅니다. 사실 뭐 리눅스도 꼭 성능이 절대적으로 좋아서 쓰는건 아니잖습니까? :-)
그런 것이라고 생각합니다.
즐거운 하루되세요.
최준호입니다. 다른 컴이라서...말씀하신대로 저는 참고삼아 - 메
최준호입니다. 다른 컴이라서...
말씀하신대로 저는 참고삼아 - 메타데이터의 안정성과
크래시 이후 복구시간 문제를 해결하는 또 하나의 방법
- 에 대해서 말씀드린 것이지 FFS의 신기능이 리눅스의
새 파일시스템에서의 저널링 이라는 의미라고 볼 수는
없겠죠.
몇년동안 조용하다가 동시다발적으로 새 파일시스템들이
번창(?)하는 것은 리눅스의 엔터프라이즈 시장 진입에
있어서 그 때가 되었음을 의미하는 것이라고도 볼 수
있겠죠. 다만 저는 여러개 놓고 고르는 것은 딱 질색이라
(그래서 FreeBSD가 좋은지도 모르죠. 고를게 별로
없는지라...) 분명히 어느쪽으로 수렴하지 않을까
생각합니다.
p.s. 2.4 커널도 바뀌는게 많아서 2.5가 있음에도 그것도
개발버전 취급하는게 아닌가... 하는 생각도 듭니다. :)
xfs, jfs, reiserfs, ext3도 모두 production level은
아니니까요. 어느정도는 개발 버전 취급하는게 정신적으로
편하지 않을까 합니다. 나중에 모두 기본 커널 안에
들어오면 더 빠르게 수렴성을 갖겠죠.
ReiserFS가 가장 먼저 기본 커널에 포함되었고 요즘은 EXT3가 그
ReiserFS가 가장 먼저 기본 커널에 포함되었고 요즘은 EXT3가 그리고 최근엔 JFS(앨런콕스 patch에)가 포함되고 있습니다. production level에서 쓰라고 만든겁니다. 그 만큼 오랜시간 동안 시행착오 많이 겪으면서 지금 뭘 선택해야하나 고민할 지경에 이른겁니다. 몇년동안 조용했던게 아니라 몇년 동안 계속 시끄러웠습니다. 근래에 저널링 파일시스템이 나온게 아니죠. (물론 리눅스에서의 저널링 파일시스템 말이죠.)
너무 많은게 불만이라고 하셨는데 저는 수년 동안 거의 변화없는 프비의 파일시스템이 더 불만입니다. 시각의 차이겠지요. 저는 뭐든지 획일적인건 싫어하는지라.
EXT3는 EXT2 + 저널링입니다. 그러니 Ext3의 안정성을 문제 삼는건 ext2의 안정성을 문제삼는 것과 비슷하죠. 레드햇쪽에서도 Ext3를 7.2부터 기본 파일 시스템으로 채택하면서 상당히 많은 테스트와 패치를 가했죠.
XFS는 뭐 페르미랩에서 쓰고 있어요. 그거 말고 더 언급하지 않아도 되겠죠? 저 위에 URL따라가면 충분한 레퍼런스가 기다리고 있습니다. 무시 무시한 대용량 스토리지나 클러스터 규모에서 만족하면서 쓰고 있다는게 무얼 의미할까요?
이걸 왜 아직도 스탁 커널에 넣어주지 않는지 XFS 유저들은 불만이 상당하답니다.
ReiserFS는 처음에는 NFS나 Qmail 과 문제가 있었으나 해결된 상태구요. 초기 2.4 커널과 다소 문제가 있었다고 합니다. 지금은 문제가 없지요.
또 올해말에 몇가지 단점을 개선한 ReiserFS4가 출시될 예정입니다.
2.4 커널의 개발버젼 취급이라... 아주 초기 2.4 커널이 다소 문제가 있었지만 2.4.10 이후로 2.2 커널 정도의 안정성을 확보하고 있다는 평가를 받고 있습니다. 몇가지 2.5 커널에서 2.4로 백포트되는 기능도 있지만 기본적으로 리누스 토발쯔는 커다란 변화를 주는 기능은 2.4에 넣지 않도록 하고 있지요.
2.4커널이 개발버젼 취급이라니 :-) 명확한 근거 부탁드립니다. F.U.D는 질색이라.
- FFS가 특히 최근 3-4년간 많은 변화가 있었습니다. Softupd
- FFS가 특히 최근 3-4년간 많은 변화가 있었습니다. Softupdates의
도입, OpenBSD에서 dirhash의 도입, dirpref의 도입, 복수의 snapshot
기능, background fsck, 포맷 안하고 파일시스템 크기를 늘리는(주로
vinum을 위한) growfs 등입니다. 근간이 되는 ufs는 최근에 ufs2가
개발 버전에 도입되고 있습니다. 목적은 주로 엔터프라이즈급 성능
향상입니다. 물론 겉보기는 같지만, FreeBSD 2.x대에 비하면 엄청난
기능/성능 향상이죠. 이정도면 충분한 변화라고 봅니다. :)
FreeBSD에서는 현재의 FFS 이상 더 좋은 파일시스템이 당장 등장할
가능성이 별로 없어 보입니다. 사용자층이 적어서 그런지 대기업이
자기 파일시스템을 포팅 안해 그런건지는 잘 모르겠습니다만...
- ac패치는 개인적으로 개발자 버전 또는 사적 버전으로 여기고 있습니다.
- 커다란 변화를 싫어하는 바로 그 리누스 토발즈가 2.4 한중간에
VM을 바꾸었죠. :) 그정도면 FUD는 아니라고 생각합니다.
물론 저도 2.4.10 이후 정도면 큰 불만 없습니다.
--
익스펙토 페트로눔
Suse 같은 배포판이나 Mandrake 같은 배포판은 벌써 여러가지 저
Suse 같은 배포판이나 Mandrake 같은 배포판은 벌써 여러가지 저널링 파일시스템을 설치시 선택할 수 있도록 하고 있습니다. 당연히 엄격한 테스트를 통과했으니 탑재했겠죠. :-) ReiserFS, Ext3, JFS, XFS... 골라서 설치되도록 벌써 배포판이 나왔다는겁니다.
그리고 1999년도의 컬럼을 가지고 아직도 내세우는 곳이니 알만합니다. 그러니 초기 2.4 커널의 문제점을 아직도 지적할만하군요. BSD도 버그 하나만 나오면 각오하셔야 할겁니다. *웃음* 농담입니다. :-)
ac패치는 리누스가 승인하지 않은 패치긴 하지만 리누스 자신도 공식버젼이라는건 없다고 인정하고 있습니다. 또 ac패치도 리누스의 버젼에 곧 포함된다는 예고판이죠. 또 리누스 버젼의 커널에 포함되지 않은 패치라고 불안정하다는 근거는 어디에도 없습니다. 그리고 이런 고민을 하지 않아도 되는건 당연히 배포판 업체가 테스트를 거쳐서 내놓으니까요.
- *BSD에 대한 언급은 여기서는 불필요하므로 하지 않겠습니다.
- *BSD에 대한 언급은 여기서는 불필요하므로 하지 않겠습니다.
- 패치의 불안정성 여부이든 중요한 것은 얼마나 정식 버전에
반영되는지라고 봅니다. 배포판 회사에서 사적으로 붙이는
것이든 ac패치든 자체적으로 테스트는 물론 하겠습니다만
그것이 정식 커널(그런게 없나요?)에 포함되었다는 것은
그만큼 믿을만 하다는 의미이겠죠.
공식 버전에 없어도 충분한 의미를 갖는 패치들이 많이 있습니다만,
때로는 믿을만한 리눅스 커널이라는게 어떤 것인지 헷갈릴
때가 있게 됩니다. 그 한가지 기준이 정식 릴리즈 커널이라고
생각합니다. 가령 래드햇판 커널 2.4.10와 SuSE판 커널 2.4.10,
Mandrake판 커널 2.4.10 안에 들어있는 파일시스템 종류부터
다르다면 사용자는 분명히 헷갈립니다. 그 차이점을 수용할 수 있는
사람이라면 상관 없겠지만... 그래서 때로는 분방하지만 중심을
잡는 것이 필요하고, 그것이 커널 메인테이너의 일이 아닌가 합니다.
솔직히 저는 배포본 업체를(얼마나 유명하든) 별로 믿을 생각은
없군요.
--
익스펙토 페트로눔
아 추가로... *BSD같으면 안정 버전 도중에 새 파일시스템을추가하
아 추가로... *BSD같으면 안정 버전 도중에 새 파일시스템을
추가하지 않습니다. :< 개발 버전에 먼저 넣고 다음번 안정
버전에 넣겠죠. 제가 BSD에 젖어서 보수적이 되어 버린 건지도
모르겠습니다만...
--
익스펙토 페트로눔
BSD방식에 대해서 뭐라고 할 생각은 없습니다. 세상은 양면성이 존재하니
BSD방식에 대해서 뭐라고 할 생각은 없습니다. 세상은 양면성이 존재하니까.. 그게 BSD의 단점일 수도 장점일 수도 있겠네요.
그런데 말의 뉘앙스가 BSD라면 이렇게 안할텐데 리눅스는 저리하니까 BSD가 더 안정적이다는 말을 하고 싶으셨던가 봅니다. 그러나 그건 충분한 근거가 못된다는건 아시고 계실듯합니다.
리눅스는 리눅스의 길이 있고, *BSD는 *BSD의 길이 있죠.둘은
리눅스는 리눅스의 길이 있고, *BSD는 *BSD의 길이 있죠.
둘은 안정 버전의 구성과 개념, 보는 관점부터 다르므로 직접
비교할 대상이 되기는 어렵다고 봅니다. 심지어 *BSD 사이도
다르니까요. 다만 이런 동네도 있더라.. 하고 생각해 주시면
감사하겠습니다.
개인적으로는 emacs가 가장 깐깐해 보입니다. :P
--
익스펙토 페트로눔
대기업에다가 ext2 는 불안하니 reiserfs 로 하라고 추천했다가,
대기업에다가 ext2 는 불안하니 reiserfs 로 하라고 추천했다가,,
reiserfs 화일시스템이 두번이나 나갔네요..
지금은 쉬쉬하고 있는데 참 난감 했습니다..
Reiserfs 는 홈피 패치만 잘 해주면 속도도 좋고 안정한데..
Reiserfs 는 홈피 패치만 잘 해주면 속도도 좋고 안정한데..
2.4.18 이전버전은 패치 안해주면 그야말로 experimental 이라는 --;
덧붙여서...40G정도에 XFS나 JFS를 꼭 쓸필요는 없지 않을까.
덧붙여서...
40G정도에 XFS나 JFS를 꼭 쓸필요는 없지 않을까...도
생각해 볼 수 있을 듯...
JFS는 현시점에서는 데이터나 테스트를 위해서라면 쓸만하지만... 서비스에는 무리가 있고...
실질적으로 일반적으로 쓰는 파일 작업은 큰차이가 나지 않을 것 같습니다...
테라급이라면... 어쩔 수 없겠습니다만...
뭐 일반적으로 그렇더군요.수 테라나 기가급 대용량에서는 XFS나
뭐 일반적으로 그렇더군요.
수 테라나 기가급 대용량에서는 XFS나 JFS가 거의 필수가 아닐까 싶습니다.
일반 데스크탑이나 소규모 서버나 워크스테이션에서는 굳이 XFS가 필요하지 않을 수도 있습니다. 그러나 모르죠. 요즘은 개인유저들도 대용량 멀티미디어 파일을 다루고 있고 스토리지 용량도 기하급수적으로 증가하고 있으니까요. 조만간 필수인 시점이 오겠죠.
음... 벤치마크를 해보면... JFS와 XFS는 비슷한 성능을 보입니다
음... 벤치마크를 해보면... JFS와 XFS는 비슷한 성능을 보입니다만...
실제로 문제는 JFS는 기능이 되는 것이 없다는 것이 문제고...
실제적으로 제대로된 녀석은 XFS밖에 없는데...
1.0.2부터는 제가 쓰는 시스템 마다 상당히 문제를 일으키고 있어서... 사용하지 못하고 있습니다...
reiserfs는 최근 버전으로 해보아도 과도한 파일 작업시... 파일이 아예 사라져 버리는 것이 여전했습니다...
그런데... ext3도 곤란한 것이... 여전히 레드햇 7.3에서도... experimental이라서리...
그리고... 10~20%정도 퍼포먼스가 떨어집니다...
XFS 1.1 나왔습니다. 그리고 CVS에서 최신 버젼을 받아서 써보
XFS 1.1 나왔습니다.
그리고 CVS에서 최신 버젼을 받아서 써보는것도 한가지 방법이 될 수 있습니다.
최근 2.4.19-rc1 에 xfs 1.1가 패치된 버젼을 받을 수 있더군요.
ReiserFS는 한 1년도 훨씬전에 웹서버에 사용했었는데 굉장히 안정적이었습니다. 불안정한 경우는 커널 버젼과의 mis-match 문제일 수도 있습니다.
ext3는 그냥 ext2에 저널링 기능만 살짝 추가한 놈이라서 ext2랑 안정성은 차이날게 없습니다. 그래서 레드햇이 가장 오래된 이 놈을 기본적으로 채택한것이구요.
성능 튜닝에 대해서는 아래에 있는 IBM의 컬럼을 읽어보시면 도움이 될겁니다.
우씨... "하드디스크"가 "히딩크"로 보이다니 -_-;
우씨... "하드디스크"가 "히딩크"로 보이다니 -_-;
우쓰...이론..지는 히딩크가 테란으로 생각되네염...흐흐
우쓰...이론..지는 히딩크가 테란으로 생각되네염...흐흐
하하....존경하는 우리의 히딩크 스승님.PS.저는 제 데스크탑
하하....존경하는 우리의 히딩크 스승님.
PS.저는 제 데스크탑 컴퓨터에 80GB 하드2개를 묶어서 RAID0으로 구성할 생각인데,
그 곳에는 700MB짜리 영화파일만 담아둘 생각입니다.
그래서 이것저것 알아봤는데,XFS가 최적인 것으로 결론 났습니다.
조만간에 두개의 FAT32하드를 완전히 비우고,XFS로 옮길 예정입니다.
전 저널링이 저글링은 보이는데 어떻하죠? 하하
전 저널링이 저글링은 보이는데 어떻하죠? 하하
현재 히딩크는 정말로 용감하게 싸웠습니다 -_-^?토론 하시는 분
현재 히딩크는 정말로 용감하게 싸웠습니다 -_-^?
토론 하시는 분들께 죄송 ㅜ,.ㅡ
좀 빗나간 이야기입니다만, 간단한 소개와 질문을 드립니다.커널 2
좀 빗나간 이야기입니다만, 간단한 소개와 질문을 드립니다.
커널 2.2.x 에서는 압축파일 시스템 e2compr 프로젝이 있었는데, 커널 2.4.x 에서 없어졌네요.
e2compr 은 chattr 명령어등을 통해서 ext2 를 압축파일 시스템으로 만들어주고자 하는 프로젝입니다.
JFFS2 가 있는데 얘는 MTD 연동하여 플래시 파일 시스템으로서만 동작하네요. 메모리 잡는 거 말고, 파일로서 루프백 마운팅이 안 되더군요. 혹시 성공하시분? JFFS2 는 JFFS 에다가 압축기능을 포함시킨 것으로 알고 있습니다. 저널링도 되고요.
ext3 는 chattr 로서 압축 플래그를 온 시킬 수 있지만,
실제적으로 압축기능은 작동하지 않는 듯 합니다.
실제로 커널 컴팔할때도 ext2 디렉내에 zlib 나 기타
압축라이브러리 링킹이 언뜻 안 보이네요. 뭐 자세히 보진 않았지만..
ext3 의 저널링 기능에 압축 기능까지 제공하는
파일시스템 뭐 좋은 거 없을까요?
디스크값도 무지 싼데 굳이 압축기능이 필요한 이유라도?아...임베
디스크값도 무지 싼데 굳이 압축기능이 필요한 이유라도?
아...임베디드에 필요한가요? ㅡ ㅡ? (플래쉬 메모리??)
임베디드에서 작은 램에 많은 디스크를 쓰고 싶어서지요~ ^^플래시
임베디드에서 작은 램에 많은 디스크를 쓰고 싶어서지요~ ^^
플래시 디스크가 아닌.. 램디스크로서~ ^^;
친구 중에 reiserfs 를 썼던 친구가 있는데 웬지 모르지만
친구 중에 reiserfs 를 썼던 친구가 있는데
웬지 모르지만 파티션이 날아가버렸던 적이
있었습니다. 저널링이라고 꼭 안전한건 아닌
것 같더군요
맞습니다.reiserfs나 jfs, xfs는 metadata저널링을
맞습니다.
reiserfs나 jfs, xfs는 metadata저널링을 채택했습니다.
따라서 data 자체는 정전이나 크래쉬 상황이 올 경우 손실 될 수도 있습니다.
그 결과로 장애시 파일의 일부분이 저장되지 않는다거나 손실 될 수 있지만, metadata에 대한 저널링을 수행하니 파일 시스템 자체가 깨지는 경우는 거의 없다는게 장점이죠. data까지 저널링하려면 상당한 오버헤드를 각오해야할겁니다.
결국 trade-off의 문제라고 볼 수 있습니다.
저널링이 급작스런 상황에 대해서 상당한 안정성을 보장한다는 것이지 100% 모든 상황을 커버할 수 있다는건 아닙니다.
전 ext3, reiserfs, jfs를 써봤습니다.성능 면에선 re
전 ext3, reiserfs, jfs를 써봤습니다.
성능 면에선 reiserfs가 가장 좋은 것 같았습니다.
jfs는 커널 버전에 상관없이 패치를 적용할 수 있어서 임베디스 시스템에 사용해 보려고 서봤는데 안정성에 높은 점수를 주고 싶습니다.
그러나 최종적으로 제 모든 하드 디스크에 사용되는 파일 시스템은 ext3가 됐습니다.
선택하게 된 이유는 리눅스 박스가 부팅하지 못하게된 경우가 발생했는데 jfs나 reiserfs로 했을 경우엔 이 파일 시스템을 인식해 주는 다른 리눅스 박스로 가져가서 일을 해야만 했습니다만, ext3의 경우 현재의 아무 배보폰 커널을 가져다가 부팅만 해서 에러를 수정할 수 있었기 때문이었습니다.
그러나 최근 배포본이 대부분의 파일 시스템을 기본 지원하므로 이런 걱정 없겠죠?
xfs는 아직 사용해 보지 않았지만 전 성능은 보통인 jfs를 추천합니다. 안정성은 reiserfs보다 좋은 것 같습니다.
작은 파일들의 경우는 ReiserFS성능이 아주 좋다고 들었습니다.
작은 파일들의 경우는 ReiserFS성능이 아주 좋다고 들었습니다.
그러나 수 기가에서 테라급이되는 경우에는 이런 일들을 잘하도록 설계되었고 오랬동안 테스트된 XFS나 JFS가 뛰어나다고 합니다.
주로 수 기가나 테라급 datafile을 다루는 DBMS시스템에서 의미가 있는 이야기겠죠. XFS의 경우가 좀 더 리눅스에 일찍 포팅되어서 그런지 ACL이나 NFS, LVM, Quota 지원등 기능면에 있어서 JFS보다는 조금 더 낫지 않나 생각됩니다.
JFS는 아직 쿼터 지원이 안되고 NFS지원은 되고 있으나 완전하지 않습니다. ACL은 구현중인것 같구요. LVM은 다들 지원하는것 같더군요.
XFS의 경우 Fermilab에서 사용되어지고 있습니다. 레퍼런스가 충분히 성능과 안정성을 입증해주고 있습니다.
The D0 Experiment at Fermilab
"At the D0 experiment at the Fermi National Accelerator Laboratory we have a ~150 node cluster of desktop machines all using the SGI-patched kernel. Every large disk (>40Gb) or disk array in the cluster uses XFS including 4x640Gb disk servers and several 60-120Gb disks/arrays. Originally we chose reiserfs as our journalling filesystem, however, this was a disaster. We need to export these disks via NFS and this seemed perpetually broken in 2.4 series kernels. We switched to XFS and have been very happy. The only inconvenience is that it is not included in the standard kernel. The SGI guys are very prompt in their support of new kernels, but it is still an extra step which should not be necessary."
"저널링 파일시스템" 에 대해 자세히 모르는 분들을 위해서 간단하게 소개
"저널링 파일시스템" 에 대해 자세히 모르는 분들을 위해서 간단하게 소개를 해주시면 좋겠습니다
IBM사이트에 올라온 컬럼인데 아주 훌륭합니다.각각의 저널링 파일시스
IBM사이트에 올라온 컬럼인데 아주 훌륭합니다.
각각의 저널링 파일시스템의 특성 및 성능 향상 팁까지 상세히 되어 있습니다.
http://www-106.ibm.com/developerworks/library/l-fs.html
http://www-106.ibm.com/developerworks/library/l-fs2.html
http://www-106.ibm.com/developerworks/library/l-fs3.html
http://www-106.ibm.com/developerworks/library/l-fs4.html
http://www-106.ibm.com/developerworks/library/l-fs5.html
참고로 한글로 번역된 것도 있습니다.http://www-903.i
참고로 한글로 번역된 것도 있습니다.
http://www-903.ibm.com/developerworks/kr/linux/library/l-fs.html
http://www-903.ibm.com/developerworks/kr/linux/library/l-fs2.html
http://www-903.ibm.com/developerworks/kr/linux/library/l-fs3.html
http://www-903.ibm.com/developerworks/kr/linux/library/l-fs4.html
http://www-903.ibm.com/developerworks/kr/linux/library/l-fs5.html
http://www-903.ibm.com/developerworks/kr/linux/library/l-fs6.html
http://www-903.ibm.com/developerworks/kr/linux/library/l-fs7.html
http://www-903.ibm.com/developerworks/kr/linux/library/l-fs8.html
http://www-903.ibm.com/developerworks/kr/linux/library/l-fs9.html
http://www-903.ibm.com/developerworks/kr/linux/library/l-fs10.html
댓글 달기