파일시스템 탐구생활

koseph의 이미지

우선!!
이 실험이 어떤 특정 파일시스템의 우수성을 확인하기 위한 실험이 아님을 밝힙니다.
===============================================================================

오늘 갑자기 아주 오래전에 시험해 봤던 간단한 실험을 몇몇 파일시스템에 해보았습니다.

1. 한 디렉토리 내에 디렉토리 10만개 생성하고 목록 보고 삭제하기
2. 한 디렉토리 내에 빈 파일 100만개 생성하고 목록 보고 삭제하기

뭐, perl로 간단하게 짰습니다.

실험한 파일시스템은
1) Linux XFS (openSUSE-11.0-DVD-x86_64)
2) Linux reiserfs (openSUSE-11.0-DVD-x86_64)
3) Linux ext3 (openSUSE-11.0-DVD-x86_64)
4) FreeBSD UFS (7.0-RELEASE-amd64)
5) Solaris 10 ZFS (for Intel)
이렇게 해봤습니다.

우선 이 실험에서 ext3와 FreeBSD UFS는 좀 논외로 쳐야 할 거 같습니다. 사실 이 파일시스템은 애시당초 별 기대도 안했습니다만....
ext3는 디렉토리를 31,998개, 파일은 280,179개 밖에 생성 못합니다.
FreeBSD UFS 역시 디렉토리는 32765개, 파일은 백만개를 만들어 냅니다. 그리고 속도가 유독 느리더군요. 파일 백만개 생성하는데 4:58:10.69가 걸렸고 파일이 증가함에 따라 시스템 부하도 따라서 증가합니다. 그리고 삭제는 너무 시간이 많이 걸려서 시간 재다가 포기.... 5가지 파일시스템 중 가장 느렸습니다.

어쨌거나 위의 실험을 통과한 파일시스템은
1) Linux XFS
2) Linux reiserfs
5) Solaris 10 ZFS
입니다.

그 중에서도 역시 예상대로 reiserfs가 비교 불가할 정도로 빨랐습니다. 역시 작은 파일과 쪽수에 강한 파일시스템입니다.

reiserfs의 디렉토리 십만개 결과입니다. 순서는 생성, 목록보기, 삭제입니다.

real    0m8.771s
user    0m0.732s
sys     0m7.416s
 
real    0m0.811s
user    0m0.244s
sys     0m0.352s
 
real    0m3.661s
user    0m0.048s
sys     0m3.612s

그리고, 이번엔 reiserfs의 파일 백만개

real    2m16.422s
user    0m8.525s
sys     1m25.369s
 
real    1m27.725s
user    0m4.564s
sys     0m21.165s
 
real    1m3.728s
user    0m1.432s
sys     1m1.076s

다음은 XFS의 디렉토리 십만개 결과이구요. 마찬가지로 순서는 생성, 삭제입니다. 목록보기는 깜빡 자료가 빠졌군요. 제 기억으론 목록보기는 한 20초 걸린 거 같네요.

real    2m2.181s
user    0m1.148s
sys     0m21.933s
 
real    1m41.132s
user    0m1.672s
sys     0m24.770s

그리고, 이번엔 XFS의 파일 백만개

real    25m13.004s
user    0m22.949s
sys     11m16.518s
 
real    2m2.615s
user    0m3.600s
sys     0m41.675s
 
real    17m48.730s
user    0m2.276s
sys     3m10.088s

마지막으로 Solaris ZFS입니다.
역시 순서는 위와 동일
real    1m17.80s
user    0m1.77s
sys     0m19.05s
 
real    0m2.15s
user    0m0.91s
sys     0m0.93s
 
real    0m20.85s
user    0m1.68s
sys     0m12.14s

이번엔 파일

real    2h18m34.86s
user    0m59.74s
sys     9m17.34s

11만개가 넘어서면서 서서히 속도가 떨어지기 시작하더니 20만개가 넘어가니 하세월!!

리스트 실패

ls: Resource temporarily unavailable

삭제는 .....
시간 재는 거 포기.... 2시간 넘게 걸어놨는데 아직도 지우고 있군요.

결론
위의 결과만 가지고 보면,

reiserfs > XFS > ZFS 정도라고 봐야겠네요.
물론, 디렉토리와 파일의 경우 서로 다른 거동을 보이지만.....
저는 개인적으로 XFS에 더 많은 점수를 주고 싶고 경험상 역시 XFS가 가장 좋았습니다.

이 정보를 잘 활용하시면 몇 가지 시스템 취약점을 발견할 수도 있습니다.
파일을 왕창 만드는 크래킹 공격을 당하는 경우라면 쪼금 유용할 수도 있겠죠.
그리고, 역시 제조사의 마케팅 자료는 믿을 게 못된다는 생각이 드네요.
또 하나, 리눅스의 네이티브 파일시스템이라 할 수 있는 ext2, ext3 파일시스템은 오래되었긴 하지만 역시 성능 면에서는 분명히 한계가 있군요. 역시 /boot 전용으로 쓰기 딱입니다.

jachin의 이미지

한동안은 xfs를 오랫동안 써야 할 것 같군요.
====
( - -)a 이제는 학생으로 가장한 백수가 아닌 진짜 백수가 되어야겠다.

atie의 이미지

zfs는 TimeSlider로 응용 프로그램화 해 놓으니 데스크탑 사용자에게는 매력적인 물건이 되겠더군요.
----
I paint objects as I think them, not as I see them.
atie's minipage

----
I paint objects as I think them, not as I see them.
atie's minipage

warpdory의 이미지

FreeBSD 의 USF 는 기본 모드가 동기모드 입니다. 마운트 옵션에서 비동기 모드로 바꾸면 상당히 빨라집니다.

그것도 한번 테스트해보면 위의 수치보다는 훨씬 좋은 결과가 나올 겁니다.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.
http://akpil.egloos.com


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

koseph의 이미지

알려 주신대로.....

sync: 4:58:10.69 55.0%
async: 2:54:56.69 94.6%
async+noatime: 1:55:22.76 92.6%

생성시간이 약 2시간 정도 줄어들더군요. 하지만 시스템 부하는 더 커져서..... OS는 무지하게 바빠지는군요. ㅎㅎㅎ

주가로 noatime까지 넣어서 해보았습니다. sync일 때보다 2/3정도까지 줄어 드는군요.
그래도 엄청 느리네요. ㅠㅠ

---------------------------------
There's always another way, dear.

mirr의 이미지

xfs 가 좋긴 좋은데 단점은 파일시스템이 깨지거나
뻑났을때 경고가 거의 없고, 경고를 내는 순간이 거의 짧거나,
경고가 나오는 순간에 거의 바로라고 할만큼 깨집니다.
게다가 파일시스템 체크시간은.......어마어마합니다..
특성상 대용량 스토리지나 파일등에 사용하기 때문에 더더욱
체감시간은 극악으로 느껴지게 됩니다....
그런 단점만 뺀다면 솔직히 저도 XFS 에 점수를 더 주고 싶습니다...

------------------------------------------------------
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.

내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.

ggeagle의 이미지


파일시스템은 시스템에서 돌아가는 프로그램의 유형이 주로 어떤 것인가에 따라 장점이 단점이 될 수 있고 또 그 반대가
될 수 있습니다.
ext2 와 비슷한 비트맵류의 (요즘의 일부시각으로 볼 때) 소형 파일시스템은 시스템이 소형일 때,소형이든 대형이든
소형의 스타일로 파일컨텐츠들이 플밍된 프로그램이 주로 돌아갈 때,즉 많은 IDC 에 있는 작은 사이트의 서버들정도까지
보다 큰 목적까지 수용가능하게 설계된 어떤 파일시스템보다 효율적일 수 있습니다.
큰 범위까지 수용가능하게 플밍된 파일 시스템들의 자료구조는 비트맵형식보다 몇단계의 트리구조를 더 거쳐 최종 블럭에 액세스되므로
그것이 필요치 않은 소형의 서버들에는 불필요한 부하가 될 수 있습니다.

참고로 위의 내용은 실험상의 것이며 실제 파일시스템과 디스크에 대해 지식을 갖고 있는 능숙한 플머는 어떠한 파일시스템에서도
한 디렉토리(디렉토리 역시 블럭 카운트가 증가하지 않을만치의 용량을 갖게 하는 것이 중요하죠),한 인덱스 내에 심각히 고려된 용량과 수를
할당하는 플밍을 합니다.그런 고려없이 플밍된 프로그램은 데이타가 쌓일수록 그 형태에 따라 다양한 문제를 드러내게 됩니다. 어떤 파일
시스템일지라도 말입니다.....

비트맵이 B-tree 같은 류보다 분명한 장점이 있고,그 장점으로 충분한 시스템의 경우 ext2 는 여전히 유효하다는 생각을 합니다.

컴퓨터 없이도 컴퓨터를 배울 수 있을까? 8년째!

=========================

매일막걸리 한 병 = 상태메롱

koseph의 이미지

실은 이런 시험을 6년전에 했었습니다.
당시에는 Intel Pentium 3 기반의 산업용 서버였습니다.
메모리도 아주 형편 없었죠. 차이라고 하는게 하드디스크가 SCSI였다는 거.....

상황이 저널링 파일시스템이 필요했던 관계로 ext3를 쓰기로 했고 이때 XFS와 비교를 했었습니다. 물론 reiserfs도 같이 했었죠.

재밌는 건 시스템이 느릴 수록 오히려 XFS의 진가가 나타납니다. 즉 성능의 차이를 실감한다는 거죠. 오히려 요즘에 들어서 disk I/O 인터페이스의 성능과 disk의 읽고 쓰기 능력이 좋아지면서 이런 격차는 오히려 줄어드는 기분입니다.

블럭기반의 할당방식을 취하던 많은 파일시스템이 파일의 크기가 커지고 스토리지가 커지니까 꼼수로(호환성 때문에 어쩔 수 없지만요) chunk 스타일의 clustering 기반의 블럭 관리를 하게 되고 종국에는 extent 기반으로 가고 있습니다.

ext4가 대표적인 예라고 할 수 있습니다.

XFS는 블럭을 기반으로 하는 파일시스템의 한계를 깨닫고 애초부터 extent로 시작했고 따라서 파일이 커지면서 발생하는 포인터 추가 문제에서부터 각종 메타데이터의 오버헤드를 줄이기 위해 많은 신경을 썼습니다. 일단 XFS는 출발부터가 대형프로젝트를 목표로 삼았고 다행인 건 요즘 스토리지 크기가 과거에 비해 엄청나게 커져서 이젠 임베디드가 아닌 이상 대형 스토리지를 달고 나옵니다. 어찌보면 설계와 구현이 딱 드러맞는 상황인거죠.

ext3의 경우 파일시스템에서 할 수 있는 능력에 비해 정말 쓰잘데 없이 기본적으로 메타데이터를 많이 예약합니다. 데이터를 저장하기 위해 많은 메타데이터를 쓰기 때문에 스토리지에도 많은 부하를 주고 성능이 오를 여지가 없습니다.

다 아시겠지만 ext3는 기본적으로 ext2의 골격에 journaling을 추가한 형태라 GNU 라이선스를 제외하곤 저널링 파일시스템 입장에서 보면 진골이 아닌셈이죠.

그뿐 아니라 ext3의 경우 디렉토리 내에 파일이 1만개 이상 되면 속도 저하가 일어나기 시작하는데 이 정도가 심해도 너무 심하다는 겁니다. 물론 개발자가 그렇게 하지 않도록 하면 된다고 할 수 있겠죠? 문제는 기업용 솔루션으로 쓰기에는 그 한계가 분명하다는 겁니다. 이건 느린 시스템에서 더 좋지 않은 결과를 초래합니다.

그래서 저는 /boot 영역 외에는 쓰질 않는다는 것이구요. 사실 이런 부분은 저널링이 거의 필요없는 부분이기도 하구요.

제 이야기는 ext2가 나쁘다가 아니구요. 기업용으로는 전혀 어울리지 않는 파일시스템이라는 겁니다. 그래서 솔직히 RedHat이 RHEL에 ext3를 고집하고 있는 이유를 알다가도 모르겠습니다. 어차피 스토리지 내에 자료는 백업 안하고 날리면 복구할래도 엄청난 비용과 시간이 드는 건 어쩔 수 없습니다.

---------------------------------
There's always another way, dear.

ggeagle의 이미지

파일시스템을 바꿔볼까 하는 초보 시스템관리자나 프로그래머가 오해할 소지가 있기 때문에 짧은 답변을 드립니다.

귀하께서 하신 실험의 내용은 개발자가 그러한 경우가 발생하지 않도록 하면 된다가 아니고
자료구조에 관한 충분한 고민을 거친 80-90년대의 플머들은 파일시스템의 어떤 유형과 관계없이 그런 플밍은 하지
않습니다.했다면 그야말로 장난이거나,그 프로그램이 특별히 큰 자료구조의 경우의수를 배제하고 작은 목적으로만 플머가 제한
하여 설계했거나,그도 아니면 완전 초보자이겠습니다.
뭐 요즘의 현역들은 안그렇다면 할말은 없습니다만 플밍으로 한기침씩 하시는 분들은 아무리 RDBMS 가 어쩌고 해도 범용의 이식성을 고려하지 않아도 된다면
자신 고유의 자료구조를 설계하여 사용하고 그 기반은 비트맵과 블럭테이블과 트리구조의 짬뽕입니다.
어렵게 볼 것도 없이 수기가의 요즘 온라인 게임을 설치해 보기만 해도 그것이 돌아가는 파일시스템이 NTFS 여서가 아니라 파일시스템과
무관하게 자료구조를 위의 실험과 비슷하게라도 해 놓은 그런 게임은 없습니다.
즉 일반적으로 쓰이는 프로그램에서 발생하기 어려운 상황을 실험하고 이를 파일시스템의 전체 성능과 커다랗게 매칭시켜 놓은
부분이 좀 염려스러웠던 것 뿐입니다.

요즘의 시스템이 대형스토리지를 갖고 있다 하셨는데 XFS 처럼 대형의 파일시스템은 현재 1테라 단일시스템을 위한 것이 아닙니다.
적어도 수테라에서 수백테라까지 확장을 고려했을 때 그 의미가 확 다가오는 것이지요
이는 자료구조의 인덱싱 기법들이 70년대에 이론적으로 발표되었고 현재도 큰 변화가 없으며,이 이론을 바탕으로 대형 파일시스템의
개발은 90년대 초 중반 많이들 시작하여 2000년 전후로 발표가 되었었는데 중소규모의 시스템에서는,즉 IDC 에 입주한 PC기반의 서버에서는 고려도
되지 않다가 단일 디스크 하나가 테라의 시대에 가까워지면서 약간씩 언급이 되고 있는 실정입니다.
기업용 솔루션......
그게 혹시 MS 나 오라클에서 주구장창 나오는 메뉴라면 패스하고 그렇지 않다면 대한민국의 많은 사이트들이 실제 내부적으로는 좀 오래된 PC서버와
구버전의 리눅스와 ext2 파일시스템에서 돌아가는 현실은......이건 기업용이 아닌가요?

고전적인 ext2 의 단일 파일 크기가 2G 인 그런 시스템으로도 충분히 수백기가내지는 수테라의 데이타를 관리할 수 있습니다.
오히려 대형의 볼륨을 하나의 파일시스템안에 굳이 넣어야 한다는 발상이 제게는 좀 어렵군요.....
마치 인덱스테이블같은 메타데이타가 하나여야만 한다는 발상처럼 어렵습니다.
여러개로 하면 됩니다.

피시방에 와서 즉흥적으로 드리는 말씀이고 전 집에 PC가 없기 때문에 매우 잘 정리된 말씀을 드리지는 못합니다.죄송합니다.

컴퓨터 없이도 컴퓨터를 배울 수 있을까? 8년째!

=========================

매일막걸리 한 병 = 상태메롱

koseph의 이미지

디렉토리 10만개, 파일 100만개를 한 디렉토리에 생성하는 정신나간 개발자가 있다면 그건 개발자가 아니고 크래커겠죠. 그리고 저도 이런 비슷한 공격을 받아 본 경험이 있습니다. 그러니 실전에서 이런 일이 생기지 않는다고 보장 못합니다.

드물긴 하지만, 사실 이런 골탕은 외부의 침입자에 의해 특정 디렉토리에 사고를 쳐서 시스템의 동작을 마비시킬 목적으로 할 수 있는 행동입니다.

아니면 프로그래머의 실수로 인해 한 디렉토리에 엄청나게 많은 파일을 생성할 수 있는 사고를 가정해도 되겠습니다.

뭔가 오해를 하신 모양인데......

좀 대상을 바꾸어 생각해 보죠.

제가 이런 실험을 한 건 개발자와는 상관이 아예 없다고 할 수는 없겠습니다. 저의 관심은 extreme한 상태에서 해당 파일시스템이 어떤 거동을 보이는가 입니다.

만약 사용하고 있는 파일시스템이 이런 취약점을 가지고 있다면 내부 관리 정책을 세우는데 반영해야 그게 제대로 정신 박힌 관리자일 것입니다.

파일시스템을 바꿔볼까 하는 초보 시스템관리자나 프로그래머가 오해할 소지가 있다 하셨는데 어떤 오해를 말씀 하시는지?

Gentoo는 일찌기 XFS 사용을 권장한 대표적인 배포판입니다. 이것 말고도 SUSE 역시 이를 지원하고 있죠.

제 주장은 1TB보다 더 작은 스토리지를 가진 서버에서도 XFS의 저널링과 ext3보다 훨씬 부드러운 성능을 맛볼 수 있다는 겁니다. 애초에 ext 씨리즈 외의 다른 파일시스템에는 관심이 없으신가 보군요.

귀하께선 이제서야 XFS와 같은 파일시스템을 언급하시고 계신지 모르지만 저는 실무에 적용한지 만 6년이 넘었습니다.

그리고, 이 글은 그런 저의 경험을 바탕으로 적고 있구요. 이런 경험을 바탕으로 전 SGI XFS의 오픈소스 공개에 대해 정말 고마워 하고 있는 사용자 중 한 사람입니다.

XFS가 쓰기 싫다면 쓰지 않으시면 되겠죠.
하지만 동일한 하드웨어 리소스로 더 나은 성능이 나온다면 당연히 관심이 가는 것 아닐까요?

그리고 ext2로도 엄청나게 큰 파일시스템을 관리할 수 있다고 하셨는데 그럼 그렇게 하십시오. 저같음 그렇게 안합니다.

There's always another way, dear.

---------------------------------
There's always another way, dear.

onion의 이미지

사실 테스트는 zfs를 제외한다면...
JFS도 테스트의 범주에 들어가야 한다라고 생각합니다.

http://linuxgazette.net/122/TWDT.html#piszcz

이 내용을 보면 zfs를 제외한 linux에서 사용되는
major 파일시스템(물론 windows계열은 제외한)의 성능테스트를 진행한바가 있는데
xfs와 jfs의 성능이 비등비등하게 나오고 있습니다.

자잘한 파일들이 많은경우에는 jfs
그리고 통파일들은 xfs쪽에 점수들이 가고있네요.

개인적으로는 2001년초부터 xfs를 사용하고 있던지라
xfs에 점수를 주는 편입니다만..
filesystem의 resize가 jfs가 더 많은 기능을 제공하고있어서
역시 비교하기는 쉽지 않은것 같습니다.

여담입니다만.. xfs파일시스템을 젠투에서 권장하기는 했지만
sgi에서 애초(?)부터 redhat용 xfs설치지원 CD제공이라던가...
지금은 망해버린 모모 배포판은 아예 xfs말고는 선택도 못했었고....
suse도 꽤나 오래전부터 xfs를 권장하고 있습죠.
아래저래 많은 사랑을 받는놈인거같습니다...^.^;

-----새벽녘의 흡혈양파-----

-----새벽녘의 흡혈양파-----

블루스크린의 이미지

댓글 토론도 잘 보고 있습니다 감사합니다.

---------------------------------------------------------------------------------------------------------
이 댓글(comment)의 수정 및 삭제를 위해 이 글에 답글(reply)를 달지말고 원 글에 댓글(comment)로 달아주세요

-------------------------------------------------------------------------------
이 댓글(comment)의 수정 및 삭제를 위해 이 글에 답글(reply)을 쓰지 말아 주십시요.
의견이 있으시면 원 글에 댓글(comment)로 써 주세요.

koseph의 이미지

http://linuxgazette.net/122/TWDT.html#piszcz

참고 자료 올려 주신 것 감사드립니다.

근데 쭈욱 보다 보니까.....
touch로 파일을 생성하는 것은 벤치마크에서는 별 의미가 없을 것 같습니다.
왜냐면, touch 자체가 너무 느려서 파일시스템 병목보다는 이거 자체가 소모하는 시간도 무시 못합니다. 그래서 빠른 파일시스템도 느린 파일시스템하고 동일하게 느려지는 효과가 생겨서 확실한 차이를 가늠하기 힘들어지죠.

file descriptor로 직접 조작해야 그 성능 차이를 느낄 수 있습니다.
더불어 벤치마크 하는 시간도 줄구요.

기왕 하는 거 제가 차라리 커널 소스를 풀어서 여러벌 복사하는 걸 해서 올렸으면 어땠을까 생각이 드는군요. 리눅스든 다른 플랫폼이든 소스 컴파일은 공통적인 요소이니까요. 파일의 크기도 제각각이구요. 기회가 된다면 직접 해서 올려보도록 하죠. 주말에 시간이 가장 많아서 아마 하게 된다면 주말에나 가능하겠네요.

기왕이면 그래프도 만들어 넣고 하면 더 좋겠죠. 근데 실험하는 것보다 정리하는 게 시간이 더 걸릴 듯.....

이러다가 주말에 이것만 붙들고 있다고 마눌님한테 쫓겨날지도. ㅎㅎㅎ

There's always another way, dear.

---------------------------------
There's always another way, dear.

다콘의 이미지

ext3의 성능이나 제약사항에 불만이 많지만 레드햇의 기본 파일시스템이고
안정적이기 때문에 사용하고 있습니다.
최근 시스템은 ISCSI SAN 스토리지 때문에 GFS(Global File System)를
사용해서 클러스터를 구성했는데 GFS1의 몇몇 부분이 맘에 안듭니다.
빨리 GFS2가 안정버전이 되면 좋겠습니다.

ext4에서는 성능도 좋아지고 제약사항도 없어지는듯해서 기대가 큽니다.
http://www.ibm.com/developerworks/kr/library/l-ext4/index.html

Quote:
ext3는 32테라바이트 파일 시스템과 2테라바이트 파일을 지원하지만
실제로는 아키텍처와 시스템 설정에 따라 제약이 좀 더 커진다. 보통 2테라바이트
파일 시스템과 16기가바이트 파일까지 낮아진다. 반면에 ext4는 1024페타바이트(1엑사바이트)
파일 시스템과 16테라바이트 파일을 지원한다. 이는 평균적인 데스크톱 컴퓨터나 서버에서
(아직!) 중요하지 않을지도 모르지만, 대규모 디스크 배열을 사용하는 관리자에게는 중요하다.

Quote:
ext3에서 하위 디렉터리를 단지 3만 2000개만 만들 수 있다는 사실에 답답함을 느꼈다면,
이런 제약이 ext4에서 사라졌다는 사실에 안도의 한숨을 쉬리라.
koseph의 이미지

좀 씁쓸한 것은 이런 문제를 제기한 것이 너무나 오래되었고 스토리지가 커지면서 문제가 불거지기 시작하고 다른 배포판들이 더 나은 파일시스템을 들먹 거리면서 목을 조여오자 ext4 왈가왈부 하고 있는데 이것 역시 새로운 기술은 전혀 아니라는 것입니다.

마치, ext4의 기본 사양이 XFS 파일시스템의 기술 스펙을 다시 읽는 듯한 느낌은 어쩔 수가 없네요. 개인적으로, 저는 결국 새로운 파일시스템이 ext3를 대체할 것이라는 것을 일찌감치 예상하고 있었습니다.

RedHat은 고의적으로 ext 씨리즈를 사용하도록 강제한 면이 없지 않습니다. RedHat은 여타의 상용 유닉스처럼 단일 파일시스템을 사용하도록 한 것입니다. RHEL의 경우 관리자가 강제로 커널을 패치하여 XFS를 도입한 경우 support warranty 위반으로 지원하지 않습니다. 그리고 공식적으로 지원하지 않는다고 자랑스럽게 떠들고 있죠. 창피한 줄 모르구요.

ext3의 성능이나 제약사항에 불만이 많지만 레드햇의 기본 파일시스템이고 안정적이기 때문에 사용하셨다고 하셨는데요. 사실 선택의 여지가 없죠. 까놓고 말해서요.

또 하나 맘에 들지 않는 것은 RedHat은 오픈소스의 모든 코드를 채용할 것 같은 정책을 세우고 있었음에도 불구하고 XFS에 대해선 찬밥이었다는 것입니다. 비단 XFS만 찬밥이었던 건 아니죠.

전, 개인적으로 동일한 플랫폼에서 도입 경비가 낮다는 이유만으로 윈도보다 느려터진 리눅스 서버는 용서가 안됩니다. 사실 이런 현상은 하드웨어 벤더들에게 쓰잘데 없이 비싼 고가장비를 팔아 먹을 수 있게한 좋은 빌미가 되었고 이건 리눅스가 성공으로 가는 게 아니라 자본주의 생리에 골병이 드는 경우라 할 수 있습니다.

한편으론 다행이라는 생각도 듭니다. 이런 레드햇의 앞뒤 막힌 소시지 같은 정책으로 인해 SUSE나 다른 배포판이 숨을 쉴 수 있는 기회를 제공했다는 거죠.

불행은 GNU is Not Unix의 기본정신을 RedHat 스스로 무너뜨리고 제한하고 있다는 것입니다. 그리고 어찌보면 ext4의 시장진입은 너무 늦었지 않나 생각이 듭니다.

과연 RedHat과 SGI가 모두 win-win 할 수 있는 마케팅 전략이나 기술구현 전략이 전혀 없었을까요? 시간이 그토록 많았는데.....

사용자들이 얼마나 답답하면 RH 배포판에 XFS를 쓸 수 있도록 한 배포판을 만들어 배포할 지경이었을까요?

There's always another way, dear.

---------------------------------
There's always another way, dear.

foruses의 이미지

리눅스 시스템의 거의 끝으머리 사용자입니다.

지난 주말, 제 운명을 바꿔놓을 뻔한, 1년 쓴 멀쩡한 하드 디스크가 갑자기 뻑난 사건 발생했었죠
(사실 끽끽 전조가 있었지만, 몰랐었죠. 서버랑 딴방 살림 중이라..)

통곡을 하면서 여차저차..
결국, 윈도우에서 explore2fs로 데이터를 백업 후,
말로만 듣던 우분투를 새로 설치, 허탈하게도 한방에 ntfs를 인식 후, ext3의 깨끗한 새 하드로 옮기는 중입니다.

다른 건 모르겠고, 윈도우에서 파일을 모두 인식할 수 있었던 것은 파일 시스템이 ext3였기 때문이었다고 생각하는데요,
맞나요? 혹시 다른 파일시스템이었어도 가능하다고 해도, 적어도 ext3가 복구 가능성을 높여주지 않았을까요?

송효진의 이미지

분명히 파티션매직 같은 윈도프로그램에서 ext3 를 지원하고,
명어쩌고 하는 유료 복구업체에서도 ext3 는 지원할 겁니다.
xfs, reiserfs 등등은 지원하는곳이 있는지 모르겠네요.

explorer2fs 로 인식이 가능한 정도라면 마운트 정도는 되겠지요.
우분투CD 로 부팅해서 백업가능한 상황입니다.

유료복구업체까지 가야할 중요한 데이터라면 백업부터 철저히 챙기는게 좋을거란 생각입니다.

그래서 성능이 좋은 파일시스템에 손을 들어주고 싶네요.
xfs 씁니다.

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/

foruses의 이미지

리눅스에선 마운트도 안되서 윈도우에서 백업 받은 것이었습니다.

"750기가 거의 꽉찬 하드 혼수상태"
-->리눅스 인식 실패
-->윈도우explorer2fs에서 인식되어 새 "ntfs하드"로 몽땅 카피함(굳이 ntfs하드를 쓴 이유는, 다른 분들은 윈도우에서 Ext2Fsd를 쓰면 새 ext3하드에 writing이 가능하다고 하던데, 저는 실패!)
-->"ntfs 하드"가 우분투에서만 인식되어 노는 컴에 우분투 깔고, 새로운 ext3하드로 카피(굳이 우분투를 중간 단계로 쓴 이유는, 다른 분들은 레드햇 계열에서도, ntfs하드를 마운트 할 수 있다고 하던데, 저는 또 실패!)
-->환생한 ext3하드를 원래 서버에 원래대로 갖다놓는 중....입니다.
무지 멀리 돌아갔죠? 쩝~. 그래도 데이터는 모두 복구.

음, 본의 아니게 윗 글들의 초점을 벗어난듯 ^^;;

암튼 저 같은 끄트머리 사용자 입장에서는 좋은 파일시스템이란 "일반적인 환경"에서 얼마나 자료들을 "안전하게 보관"하고 혹시 하드에 문제가 생겨도 "정상적으로 복구"시킬 확률이 높은가하는 어찌보면 저장매체 본연의 기능을 충실하게 해주는 시스템..인것 같군요. 역설적이지만, 제 경우는 속도가 너무 빨라도 골치아파요. 쉴 시간도 줄어 드니까요. ㅎㅎ

요는, "ext3하드가 끽끽대다가 정신잃고 마운트도 안될 때, 윈도에 물려서 여차저차하면 데이터를 모조리 살려낼 수 있다"는 사례에 대한 정리 글이었습니다.

송효진의 이미지

explorer2fs 제작자들이 시간이 남아도는게 아닌 이상
ext2 소스를 기반으로 응용한 것이겠지요.^^
단순히 fsck 를 하면 될 상황이었을것 같네요.
보통 마운트횟수나 fsck 했던 기간으로 반드시 fsck 하라는 메세지가 나옵니다.
오래도록 검사 안했으니 하라는거죠.

그게 아니고 정말로 오류난 파티션을 읽어냈다면 explorer2fs 제작자가 정말 대단한 거겠지요.

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/

foruses의 이미지

문제 터지자마자 fsck 했었는데요, 진행이 안되면서 첨 보는 에러 메세지가 떴어요. 적어놓질 않아서 기억 안나고요.
그래서 하드 연결 케이블 등을 바꿔봐도 동일.

그래서, 포기하고 위 짓거리들을 한거였고요.

그..런..데..방금 혹시나해서 새로 우분투 설치한 노는 컴(3~4년전 사양의 평범 pc)에다 고장난 하드를 물려보니,
역시 마운트 안되길래, fsck 해보니.......작동을 합니다. 쭉 체크 끝낸 후, 마운트도 되고, 파일도 읽히고. 울어야 할지 웃어야 할지.

참고로 하드 망가짐이 발생했던 서버(CentOS_5.2)는 현재 하드디스크 모두 정상작동인 것으로 봐서 본체 문제는 아닌것 같고.
그렇다면, OS문젠가요? CentOS보다 우분투가 몬가 잘 작동시킨걸까요? ㅎㅎ 음...혼란스럽군요.

암튼, 문제의 하드는 굉음이 계속되기에 A/S 보내렵니다.

곁다리 글타래가 되었군요~~.^^;;;

koseph의 이미지

우리나라에도 있습니다.
reiserfs v4, xfs까지 모두 복구해 내는 업체 있습니다. 다른 분들이 없다고 하셨는데 있습니다. 서비스 받은 지 2년 넘었습니다.
실제로 서버 사고쳐서 의뢰했었습니다.
거의 100% 살려내더군요.

There's always another way, dear.

---------------------------------
There's always another way, dear.

송효진의 이미지

그 업체말고 다른곳은 안된다면 이름을 알려주심이 마땅합니다!!!
얼른 알려주세요!

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/

koseph의 이미지

본의 아니게 업체 광고가 될 수도 있고 이런 정보를 여기에 올린다는 건 아주 부적절하네요.

어쨌든 존재합니다. 영문 K로 시작하는 회사입니다.

There's always another way, dear.

---------------------------------
There's always another way, dear.

송효진의 이미지

다행히 하나밖에 안나오는군요.
혹시나 해서 다른업체들도 찾아봤는데 이만한 스펙은 여기밖에 없는것 같군요.
유일하다면 그냥 밝혀도 무방하다고 생각되는데요.

  지원하는 운영 체제
윈도우즈 유닉스 애플 파일 시스템
Dos / WIn3.x 리눅스/BSD Mac OS FAT12/FAT16/FAT32
Win9x/Se/Me 솔라리스 Mac OS X NTFS(ver4,5)
Win2000/XP HP-Unix Ext2,Ext3,ReiserFS,FFS,XFS
WinNT/2000/2003/XP Server AIX HFS,HFS+
비스타 Netware JFS,Vxfs,UFS,ZFS
  지원하는 디바이스
레이드,어레이 인터페이스 스토리지 이동 저장 장치
모든 레이드 레벨 0-10 EIDE,SATA,SSD 시게이트,넷기어 FDD
AMI,LSI,Mylex,Accusys SCSI,FCAL,SAS EMC Zip/Zaz
AMCC,하이포인트,터렛,아답텍 노트북 넷엡 PCMCIA
선,컴팩,인텔,후지쓰,델,IBM,HP PCMCIA 히다찌 플래시 메모리,USB 메모리
산업용 설비 Firewire,USB,Fiber 기타 USB 디스크

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/

koseph의 이미지

그거 참.........

끈질기시군요. 헐헐~~~
아마 여기 말고도 또 있을지도 모릅니다. 저라고 다 아는 건 아니어서.....

There's always another way, dear.

---------------------------------
There's always another way, dear.

playhop의 이미지

많은 분들의 좋은 글 잘 읽었습니다..

중간에 논쟁이 조금 있었지만 이런 글들 많이 올라 왔음 합니다 ^^;
(KLDP에 매일놀러 오는 편이지만 주로 이런종류의 글타래들은 아무래도 적은 편인데(주로 개발관련글이 좀 많죠) 글을 보니 관심이 가고 참 반갑네요...)

뜬금없이 정리해 보자면,
ggeagle님은 그저 보여주는 결과 값에 따라, 이게 분명히 좋을꺼야 하며 따라하는 분들이 생길까봐 우려 하신것 같습니다.
(물론 따라해도 좋을것은 분명히 참고하여 따라 해야 겠지만, 단순한 수치 싸움(?)에 현혹 되시는 분이 없으시면 하는것이겠죠...)
어떤 파일 시스템이건 툴이건 간에 관리자가 가장 능숙하고 핸들링 하기 좋은 것이 가장 좋다라고 생각 합니다.
그리고 어떤면에서 ext파일 시스템은 레퍼런스가 가장 많은 파일 시스템이 아닐까 합니다. (물론 이것이 redhat이라는 이바닥의 나름 대기업(^^)에서 밀어 주는 탓도 있겠지만...물론 여기도 나쁜건만 존재 하는건 아니라고 봅니다.. 분명 많은 순기능이 존재하죠.)

뭐 저라면, 글쎄요....데이타에 관련된... 모든 부분은 그래도 마냥 보수적이고 싶네요. (너무 비겁한 변명인가요? ^,.^)

또 밀어야 하나 아니 이제 인생 자체를 밀어야 한다..... IT 관두는 젖비린내 SE (/ㅡ_-)/~

송효진의 이미지

전통과 역사의(?) xfs 도 충분히 보수적이라고 말씀드리고 싶습니다.^^

튜닝하는게 아닌 이상 포맷하고 마운트하고 검사하는게 다인데,
익숙하지 않아도 30초 이상 차이나지는 않을것 같네요;;

튜닝은 geek 영역이라서 도망===3

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/

gurugio의 이미지


글 잘봤습니다.
역시 파일시스템에 관한 이슈도 끝이 없네요.

저는 메모리 관리에 관심이 많은데 파일시스템도 연구할것이 많은것 같습니다.

----
세상을 바꾸는 것은 단 한 사람. 오직 하나님의 사람뿐이다.
개인 홈페이지가 생겼습니다 http://caoskernel.org
어셈러브를 개편중입니다 http://www.asmlove.co.kr

winner의 이미지

제가 경험이 없어서 아는 바가 없어서요.

제가 아는 것은 GRUB이 된다 정도인데 새로운 kernel이 등장하면
일단 ext부터 점검을 하기 때문에 안정적인가요?

송효진의 이미지

/boot 에는 커널이미지 외엔 거의 들어가는게 없고,
커널업데이트 외엔 write 할 일도 없죠.

즉, 저널링도 필요 없고 많은 용량도 필요 없습니다.

ext2 가 딱 맞죠.

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/

doodoo의 이미지

근데 제 경우엔 /boot 도 / [root] 안에 넣어서 xfs 로 써서
/, /home, 은 xfs.....그리고 swap 정도만 나누는데....

/boot 를 그렇게 따로 나누어야 하는 필요가 있나요?

송효진의 이미지

파일시스템이 깨질 때 꼭 쓰던파일이 깨진다는 보장이 없습니다.
따로 빼면 그나마 부팅은 되겠죠.

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/

koseph의 이미지

과거에는 LBA 문제로 인해 실린더 1024 안쪽에 부트 이미지가 꼭 있어야 했습니다. 그래서 부트 파티션을 1024번 안쪽 실린더에 할당해서 파일시스템으로 구성했죠. 통상 1번 파티션(하드디스크의 맨 바깥쪽 실린더)으로 할당합니다. 아주 작은 차이지만 부트로더가 커널 이미지를 읽을 때 가장 빠르게 읽을 수 있는 위치이기도 하죠.

보안상 통상 그렇게 합니다. /boot는 부팅할 때와 커널 설치시에만 액세스 하면 됩니다. 서비스 하는 경우에는 자동 마운트 하지 않습니다. 만약 /와 파일시스템이 하나로 되어 있다면 부팅할 때 어쩔 수 없이 따라서 올라오겠죠. 커널 이미지를 변조하는 사고에 더 취약합니다.

물론 /boot를 따로 쪼개는 것만으로 모든 게 안전하다는 뜻은 아닙니다.

취미로 리눅스를 쓰신다면 큰 문제는 아닙니다.

There's always another way, dear.

---------------------------------
There's always another way, dear.

koseph의 이미지

/boot는 많아야 100MB 정도 줍니다. 이걸 1GB 이렇게 설정하시는 경우는 없겠죠?
있으시려나?

커널을 버전별로 엄청나게 모으지 않는 이상 100MB 정도면 뒤집어 씁니다.

대부분 /boot는 부팅 때 커널을 읽어 들이면 그걸루 땡입니다. 항상 기록하는 공간이 아니죠. 설령 새로운 커널을 설치한다고 해도 그다지 시간이 많이 걸리지 않구요. 커널은 대개 업그레이드 보다는 설치를 해야 하므로 디스크에 커널을 쓰는 도중에 정전이 되더라도 grub.conf를 만지지 않았다면 그다지 문제가 안됩니다. 동일한 버전을 강제로 설치하는 경우라면 미리 사본을 만들고 하는 게 안전하겠지요.

즉, 저널링 파일시스템을 굳이 도입할 필요가 없는 겁니다.
설령 저널링을 하지 않고 기록을 하다가 뜻하지 않은 재부팅을 하거나 시스템이 죽더라도 파일시스템 사이즈가 작아서 fsck로 점검하는 경우라도 그다지 시간이 많이 걸리지 않습니다. 또한 초기 GRUB 버전은 ext 씨리즈 파일시스템 만을 지원했습니다. 그래서 본의아니게 /boot는 ext2, 3가 주로 많이 쓰였죠.

GRUB 버전이 올라가면서 이젠 ext2, 3가 아닌 XFS 파티션, reiserfs 파티션도 지원합니다. 제가 버전은 잊어먹었네요.

파일시스템 점검 순서는 무조건 ext부터 점검하는 게 아니구요. /etc/fstab에 있는 6번째 필드의 fs_passno를 체크해서 1이나 2면 fsck가 작동합니다. 1번이 먼저구요, 2번이 나중입니다. 1번은 필히 /를 가르켜야 합니다.

자세한 건 man fstab을 활용하세요.

There's always another way, dear.

---------------------------------
There's always another way, dear.

poss의 이미지

zfs 쓰시는 분은 안계신건가요?

일단, 관리는 예전 ufs에 비해서 편리한듯 합니다. fsck같은 것도 필요 없고요.

xfs는 안써봤지만, 기회되면 한번 써 보고 싶군요. ;^^

ggeagle의 이미지


제가 우연히 이 제목의 글을 읽었을 때 그 때 마침 PC방에서 파일시스템 관련 글을 좀 구상하고 있었습니다.
물론 게임도 하면서....그리고 워낙 오래전에 했던 내용들이라 맘에 드는 내용들이 나오지 않아 이곳저곳
기웃거리는 중이었구요.

ext2 가 /boot 전용이라는 말씀과
그다음 기업용 솔루션이 전혀 아니라는 연타에 제가 좀 과격했나 봅니다.
마침 그 때 파일시스템과 자료구조 일반을 좀 쓰고 ext2 의 중요성 부분을 구상 중이었습니다 ㅋ

다른 부분은 이제 다른 분들도 추가설명이 있으시고 하니 안하겠습니다만 굳이 물어보시니

"파일시스템을 바꿔볼까 하는 초보 시스템관리자나 프로그래머가 오해할 소지가 있다~"

이 부분은 하나의 파일시스템을 /boot 전용으로 다른 하나는 거의 압도적인 고성능으로 표현하신 데 이어
하나의 파일시스템을 기업용 솔루션에서는 전혀 맞지 않는다는 연타에 흥분해서 쓴 글입니다.

참고로 2000년을 전후해 B tree방식의 변형을 사용한 파일시스템이 많이 발표되었다고 말씀드렸는데
그 부근 및 그 후 얼마간 벤치마킹 같은게 많이 있었습니다.
님의 실험이나 아래 링크와 같은 플밍적인 벤치마킹말고 수학적으로 인덱싱 기법에 따르는 장단점을
증명하기까지 했었습니다.기억하기로 어느 하나가 이런 경우에도 좋고 저런경우에도 좋고,거의 대부분의 경우에도
좋은 그런 인덱싱 기법은 없다는 것이었고 여기에 동의합니다 전.

음....이미 늦었지만 그냥 짤막하게 표현하려 했다면 다음처럼 할 걸 그랬다는 생각이 듭니다.
소형의 자료구조에서는 파일시스템 자체의 성능차는 그리 크지 않으므로 해당 파일시스템을 잘 이해하고
플밍한 프로그램의 성능이 더 중요하다.그러나 자료구조가 대형화될 수록 대형 파일시스템을 기반으로 한
시스템의 필요가 커진다....이 정도로 할랍니다.


아래 두 링크를 보면 대체적으로 XFS 나 기타 B tree 인덱싱을 사용한 파일시스템이 약간 또는 조금 더 낫습니다.
하지만 어느정도 자료구조의 크기를 제한하게 되면 이 차이는 점점 줄어들게 되며 반대로 프로그래머의 역량에 의한
성능차이가 더 크게 다가오게 됩니다.

벤치마킹 예 1 : http://fsbench.netnation.com/new_hardware/2.6.0-test8/ide/bonnie.html
벤치마킹 메인 페이지 : http://fsbench.netnation.com

컴퓨터 없이도 컴퓨터를 배울 수 있을까? 8년째!

=========================

매일막걸리 한 병 = 상태메롱

송효진의 이미지

분명히 파일시스템간의 장단점이 있기에 무조건 뭐가 더 좋다고 할 수는 없겠지만,
ext2:튜닝 이 xfs:막 에 비해 월등히 뛰어난게 아니라면 xfs 쓰는게 합리적이지 않을까요?
프로그래머의 역량으로 성능을 증가시기는것은 ext2 나 xfs 나 상관없이 적용 가능한게 대부분 아닐까요?

기업용 솔루션 공급업체가 프로그램을 세세하게 조정해서 ext2 로 최적의 성능을 뽑아놨더니
그 하드웨어에 다른솔루션 얹어놓고 그 다른솔루션 업체가
'ext2 는 저널링이 안되니 우리 솔루션의 안정성을 보장할 수 없다'고
찍~ 한마디 뱉어버리면 곤란할것도 같고요.

그냥 쉽게 생각하는것도 괜찮을것 같습니다.^^

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇개 안되요~
http://xenosi.de/

Necromancer의 이미지

과거에는 파일시스템의 특성을 고려해서 프로그램 짰지만 지금은 그럴 역량이 있어도 안하는 경우가 많습니다.
회사에서 프로그램 만드시는분은 이유 다 아실걸로 압니다.

물론 디스크관련 작업이 많고 그 성능이 프로그램의 '질'을 좌우하는 중요한 요소라면(DB 등등) 그와 관련된
일정을 따로 빼죠.

Written By the Black Knight of Destruction

Written By the Black Knight of Destruction

권순선의 이미지

http://www.kev009.com/wp/2008/11/on-file-systems/

이거 말고도 파일시스템에 대한 이야기는 아주 많겠지만... /.에 갔다가 하나 낚았습니다. :-)

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.