디렉토리의 파일 수가 제한되나요?

xmlParser의 이미지

mpeg프레임을읽어서 이미지로 전환 후 디렉토리에 저장하고 있는데
이상하게 팡리이 약 1200개정도 쓰여진 후에 더이상 이미지 파일이
디렉토리에 생성이 되질 않는데.....

디렉토리에 저장되는 파일의 수가 제한되어 있나요?

pynoos의 이미지

1200 개는 많지도 않은 수입니다.
저는 20만개도 들어가는 것을 보았습니다만..

정확한 한계는 당장 생각이 나질 않는군요.

불량청년의 이미지

파일 시스템마다 다르겠지만,

보통 ext3라면 /usr/src/linux/include/ext3_fs.h 보시면

생성할 수 있는 파일 수가 define되어 있습니다.

H/W가 컴퓨터의 심장이라면 S/W는 컴퓨터의 영혼이다!

xmlParser의 이미지

error message :
file open error: Too many open files
why????? ret -1
write_image call

윗분 말씀이 맞네요. 파일이 1200개 이상 생성이 되질 않습니다.(에러
메세지만 제대로 출력했어도 삽질은 안했을건데...ㅠ.ㅠ 소스를 copy and paste
하다 보니....)

최대 생성 파일 갯수를 수정해 줄려면 어떻게 해야 하나요
ext3_fs.h 파일이 /usr/include/linux에 있는데, 어떤 부분을 수정을 해야 할지
알려주시면 감사하겠습니다.

blackmir의 이미지

에러가 "Too many 'open' files" 네요.

열려진 파일 디스크립터가 너무 많다는 뜻으로 해석됩니다.

프로그램내에서 파일을 open 한 후에 close하지 않은 것이 있는가 확인해보는 것이 좋을 듯합니다.

alwaysN00b의 이미지

blackmir wrote:
에러가 "Too many 'open' files" 네요.

열려진 파일 디스크립터가 너무 많다는 뜻으로 해석됩니다.

프로그램내에서 파일을 open 한 후에 close하지 않은 것이 있는가 확인해보는 것이 좋을 듯합니다.

더 많이 열고 싶으시면 커널 파라미터 수정 하셔야 됩니다.

쉘에서도 가능하구요.. 비슷한 쓰레드를 본적이 있는듯 합니다.

언제나 시작

simpid의 이미지

alwaysN00b wrote:
blackmir wrote:
에러가 "Too many 'open' files" 네요.

열려진 파일 디스크립터가 너무 많다는 뜻으로 해석됩니다.

프로그램내에서 파일을 open 한 후에 close하지 않은 것이 있는가 확인해보는 것이 좋을 듯합니다.

더 많이 열고 싶으시면 커널 파라미터 수정 하셔야 됩니다.

쉘에서도 가능하구요.. 비슷한 쓰레드를 본적이 있는듯 합니다.

Too many 'open' files
아닌가요?
close를 안하고 있는게 맞을것 같습니다.

디렉터리 하나에 1200개의 파일은 말도 안되죠.
win95에도 32767개쯤 들어가던데...

참고로 저희 팀 제품은... Tru64, Redhat 7.2, Windows 2000,2003, HPUX, Solaris 등등을 파일서버로 사용하는데...
하나의 디렉터리에 10000개의 폴더를 만들고.. 그 폴더안에... 1000만개 이상의 파일이 나눠져 들어갑니다.

xmlParser의 이미지

simpid wrote:
alwaysN00b wrote:
blackmir wrote:
에러가 "Too many 'open' files" 네요.

열려진 파일 디스크립터가 너무 많다는 뜻으로 해석됩니다.

프로그램내에서 파일을 open 한 후에 close하지 않은 것이 있는가 확인해보는 것이 좋을 듯합니다.

더 많이 열고 싶으시면 커널 파라미터 수정 하셔야 됩니다.

쉘에서도 가능하구요.. 비슷한 쓰레드를 본적이 있는듯 합니다.

Too many 'open' files
아닌가요?
close를 안하고 있는게 맞을것 같습니다.

디렉터리 하나에 1200개의 파일은 말도 안되죠.
win95에도 32767개쯤 들어가던데...

참고로 저희 팀 제품은... Tru64, Redhat 7.2, Windows 2000,2003, HPUX, Solaris 등등을 파일서버로 사용하는데...
하나의 디렉터리에 10000개의 폴더를 만들고.. 그 폴더안에... 1000만개 이상의 파일이 나눠져 들어갑니다.

close 는 해주었습니다. 커널 파라미터를 수정하는게 맞습니다
ulimit -a 을 주면 open이 가능한 파일 수, 최대 파일 크기등... 값을 알 수있고
ulimit -n 으로 open 최대 파일 수를 조절할 수가 있었습니다.

simpid의 이미지

xmlParser wrote:
simpid wrote:
alwaysN00b wrote:
blackmir wrote:
에러가 "Too many 'open' files" 네요.

열려진 파일 디스크립터가 너무 많다는 뜻으로 해석됩니다.

프로그램내에서 파일을 open 한 후에 close하지 않은 것이 있는가 확인해보는 것이 좋을 듯합니다.

더 많이 열고 싶으시면 커널 파라미터 수정 하셔야 됩니다.

쉘에서도 가능하구요.. 비슷한 쓰레드를 본적이 있는듯 합니다.

Too many 'open' files
아닌가요?
close를 안하고 있는게 맞을것 같습니다.

디렉터리 하나에 1200개의 파일은 말도 안되죠.
win95에도 32767개쯤 들어가던데...

참고로 저희 팀 제품은... Tru64, Redhat 7.2, Windows 2000,2003, HPUX, Solaris 등등을 파일서버로 사용하는데...
하나의 디렉터리에 10000개의 폴더를 만들고.. 그 폴더안에... 1000만개 이상의 파일이 나눠져 들어갑니다.

close 는 해주었습니다. 커널 파라미터를 수정하는게 맞습니다
ulimit -a 을 주면 open이 가능한 파일 수, 최대 파일 크기등... 값을 알 수있고
ulimit -n 으로 open 최대 파일 수를 조절할 수가 있었습니다.

전 Linux를 잘몰라서.. ulimit 란건 처음 봅니다.
제 개발용 debian 2.4 에서 해보니까... 1024 개로 나오는군요.

하지만..아무리 봐도.. 이건 open할 수 있는 최대 핸들 개수로 보이는군요.
한 디렉터리 안에 만들수 있는 파일 개수와는 상관 없는듯 합니다.

그리고.. 제가 간단하게 10000개의 폴더를 만들수 있는 코드(예전에 만들어 놓은거) 다시 컴파일 해서 실행해 봐도 잘 만들어 집니다.

추가: 방금 디렉터리 대신 파일을 만들어 봤습니다....
테스트로 딱 10000개 만들어 봤고.. 잘 됩니다.
"test..." 라는 문자열 들어가는 텍스트 파일 10000개입니다.

mosqhan의 이미지

simpid wrote:
xmlParser wrote:
simpid wrote:
alwaysN00b wrote:
blackmir wrote:
에러가 "Too many 'open' files" 네요.

열려진 파일 디스크립터가 너무 많다는 뜻으로 해석됩니다.

프로그램내에서 파일을 open 한 후에 close하지 않은 것이 있는가 확인해보는 것이 좋을 듯합니다.

더 많이 열고 싶으시면 커널 파라미터 수정 하셔야 됩니다.

쉘에서도 가능하구요.. 비슷한 쓰레드를 본적이 있는듯 합니다.

Too many 'open' files
아닌가요?
close를 안하고 있는게 맞을것 같습니다.

디렉터리 하나에 1200개의 파일은 말도 안되죠.
win95에도 32767개쯤 들어가던데...

참고로 저희 팀 제품은... Tru64, Redhat 7.2, Windows 2000,2003, HPUX, Solaris 등등을 파일서버로 사용하는데...
하나의 디렉터리에 10000개의 폴더를 만들고.. 그 폴더안에... 1000만개 이상의 파일이 나눠져 들어갑니다.

close 는 해주었습니다. 커널 파라미터를 수정하는게 맞습니다
ulimit -a 을 주면 open이 가능한 파일 수, 최대 파일 크기등... 값을 알 수있고
ulimit -n 으로 open 최대 파일 수를 조절할 수가 있었습니다.

전 Linux를 잘몰라서.. ulimit 란건 처음 봅니다.
제 개발용 debian 2.4 에서 해보니까... 1024 개로 나오는군요.

하지만..아무리 봐도.. 이건 open할 수 있는 최대 핸들 개수로 보이는군요.
한 디렉터리 안에 만들수 있는 파일 개수와는 상관 없는듯 합니다.

그리고.. 제가 간단하게 10000개의 폴더를 만들수 있는 코드(예전에 만들어 놓은거) 다시 컴파일 해서 실행해 봐도 잘 만들어 집니다.

추가: 방금 디렉터리 대신 파일을 만들어 봤습니다....
테스트로 딱 10000개 만들어 봤고.. 잘 됩니다.
"test..." 라는 문자열 들어가는 텍스트 파일 10000개입니다.

open 할 수 있는 최대 file descriptor 수 맞습니다.
man bash (man csh, man ksh, 기타 사용하는 쉘) 하셔서 ulimit (unix 에 따라 또는 쉘에 따라 limit 일수도 있음)으로 검색해 보시면 자세한 내용을 보실 수 있습니다.

집에가서 발닦고 잠이나 자자...

xmlParser의 이미지

simpid wrote:

전 Linux를 잘몰라서.. ulimit 란건 처음 봅니다.
제 개발용 debian 2.4 에서 해보니까... 1024 개로 나오는군요.

하지만..아무리 봐도.. 이건 open할 수 있는 최대 핸들 개수로 보이는군요.
한 디렉터리 안에 만들수 있는 파일 개수와는 상관 없는듯 합니다.

그리고.. 제가 간단하게 10000개의 폴더를 만들수 있는 코드(예전에 만들어 놓은거) 다시 컴파일 해서 실행해 봐도 잘 만들어 집니다.

추가: 방금 디렉터리 대신 파일을 만들어 봤습니다....
테스트로 딱 10000개 만들어 봤고.. 잘 됩니다.
"test..." 라는 문자열 들어가는 텍스트 파일 10000개입니다.

한 디렉토리에 생성되는 파일수뿐만 아니라, 용량까지 영향이있는 듯 합니다.
저도 님과 같은 테스트를 해보았습니다. 한 파일에 4바이트씩 써서 무한루프를 돌렸느데 6000개 이상이 만들어 지긴 하더군요...
아무튼 문제는 해결했습니다.

ulimit -n 6500
:lol:

xmlParser의 이미지

물의를 빚어 죄송합니다.
디버깅 한답시고 open한 파일을 close를 한했더군요.
:oops:
이러면서 배우는가 봅니다.
아무튼 답변해주신 분들 정말 고맙습니다. 꼼꼼해져야 한다는 거......
다시 한번 생각해 보네요.... :)

불량청년의 이미지

제가 써 놓은 글을 보시면 아시겠지만,

ext3에선 32000개 이상 못 만들껍니다.

ulimt에서 나오는 값은 파일 디스크립터 수입니다.

원래 목적이 한 디렉토리에 만들 수 있는 파일 수를 알아내는것 아니였나요?

ㅡ,.ㅡ; 수고하세요~!

PS : limit를 넘어서 만들고 싶다면 다른 파일 시스템을 써보던지, 커널

컴파일 한 번 해보세요~! 저도 안해봐서 될지 안될지 모르겠습니다. ^^;

H/W가 컴퓨터의 심장이라면 S/W는 컴퓨터의 영혼이다!

singlet의 이미지

불량청년 wrote:
ext3에선 32000개 이상 못 만들껍니다.

설마 이것을 말씀하시는 것입니까?
#define EXT3_LINK_MAX 32000
이건 파일 개수가 아니라 링크 개수입니다. 실제로 테스트해보면 파일 32000 개 정도는 가뿐히 넘길 수 있음을 알 수 있습니다. 십만개도 만들 수 있던데요. (십만개 제한은 아닙니다. 생각보다 오래 걸려서 중간에 그만 뒀는데 그 때까지 생성한 파일 개수가 십만여개였다는 것일 뿐. 제 시스템에서 돌린 간단한 테스트 프로그램으로는 여기까지 약 15분쯤 걸렸습니다.)

답변을 올리실 때에는 그냥 추측한 내용보다는 되도록이면 실제 결과에 바탕해서 올려주셨으면 합니다. 아니면 최소한 추정이라는 말씀이라도 붙여주시거나요.

angpoo의 이미지

참고로 말씀드리자면
#define EXT3_LINK_MAX 32000
디렉토리안에 만들 수 있는 서브디렉토리의 한계로 알고 있습니다.
. .. 두개가 필수적으로 만들어지니 32000 - 2개를 만들 수 있습니다.

angpoo의 이미지

예전에 ext2에서 파일이 2만여개가 있는 디렉토리가 만들었더니
그 디렉토리에만 접근하면 시스템이 거의 먹통이 될 정도였습니다.

테스트를 해보니 그정도까지는 전혀 아니지만 만개 2만개 넘어가니 조금씩 느려지는게 느껴지는군요.

근데 정말 한계는 몇개죠?
대충 검색해봤는데 못 찾겠네요.
추정컨데 디렉토리 파일정보 크기가 2G?가 될때가 한계가 아닐까 싶네요.

singlet의 이미지

angpoo wrote:
참고로 말씀드리자면
#define EXT3_LINK_MAX 32000
디렉토리안에 만들 수 있는 서브디렉토리의 한계로 알고 있습니다.
. .. 두개가 필수적으로 만들어지니 32000 - 2개를 만들 수 있습니다.

... 역시 아닙니다;;

말 그대로, 최대로 만들 수 있는 링크의 개수입니다. -_-;; 더 정확히는 hard-link 의 최대 개수지요. man 2 link 하신 뒤 EMLINK 부분을 보시면

Quote:
The file referred to by oldpath already has the maximum number of links to it.

내지는 그 비슷한 설명이 붙어 있을 겁니다. 여기서의 the maximum number 가 바로 해당 값입니다. ext3 에서 테스트해보시면 파일이 링크될 수 있는 최대 회수가 실제로 1(원래 파일) + 31999(링크) = 32000 임을 확인하실 수 있을 겁니다.

커널 소스의 Documentation/filesystems/ext2.txt 내용을 참고하시면 다른 한계도 찾아보실 수 있습니다. 일부 여기 적어보자면-

* 한 디렉토리 내의 최대 서브디렉토리 개수는 32768 개
* 한 디렉토리 내의 이론적인 최대 파일 개수는 130 조 개 이상
* 한 디렉토리 내의 실질적인 최대 파일 개수는 10000 ~ 15000 (이 이상일 경우 속도 저하가 심각합니다)

alwaysN00b의 이미지

simpid wrote:
xmlParser wrote:
simpid wrote:
alwaysN00b wrote:
blackmir wrote:
에러가 "Too many 'open' files" 네요.

열려진 파일 디스크립터가 너무 많다는 뜻으로 해석됩니다.

프로그램내에서 파일을 open 한 후에 close하지 않은 것이 있는가 확인해보는 것이 좋을 듯합니다.

더 많이 열고 싶으시면 커널 파라미터 수정 하셔야 됩니다.

쉘에서도 가능하구요.. 비슷한 쓰레드를 본적이 있는듯 합니다.

Too many 'open' files
아닌가요?
close를 안하고 있는게 맞을것 같습니다.

디렉터리 하나에 1200개의 파일은 말도 안되죠.
win95에도 32767개쯤 들어가던데...

참고로 저희 팀 제품은... Tru64, Redhat 7.2, Windows 2000,2003, HPUX, Solaris 등등을 파일서버로 사용하는데...
하나의 디렉터리에 10000개의 폴더를 만들고.. 그 폴더안에... 1000만개 이상의 파일이 나눠져 들어갑니다.

close 는 해주었습니다. 커널 파라미터를 수정하는게 맞습니다
ulimit -a 을 주면 open이 가능한 파일 수, 최대 파일 크기등... 값을 알 수있고
ulimit -n 으로 open 최대 파일 수를 조절할 수가 있었습니다.

전 Linux를 잘몰라서.. ulimit 란건 처음 봅니다.
제 개발용 debian 2.4 에서 해보니까... 1024 개로 나오는군요.

하지만..아무리 봐도.. 이건 open할 수 있는 최대 핸들 개수로 보이는군요.
한 디렉터리 안에 만들수 있는 파일 개수와는 상관 없는듯 합니다.

그리고.. 제가 간단하게 10000개의 폴더를 만들수 있는 코드(예전에 만들어 놓은거) 다시 컴파일 해서 실행해 봐도 잘 만들어 집니다.

추가: 방금 디렉터리 대신 파일을 만들어 봤습니다....
테스트로 딱 10000개 만들어 봤고.. 잘 됩니다.
"test..." 라는 문자열 들어가는 텍스트 파일 10000개입니다.

파일 디스크립터 확실합니다.

linux는 잘모르고

solaris 8 에서는

아마도 /etc/system.conf (확실히 생각안남) 에 커널파라미터를 설정할수있습니다.

'디렉토리의 최대 파일수' 가 아니고, '한프로세서가 열수있는 최대 갯수' 입니다.

기본적으로 3개의 파일 디스크립터를 사용하기때문에 1000개로 오해하신것 같습니다.

xmlParser님 말씀대로 하면 수정가능하고, ksh 과 csh 명령이 조금 틀립니다.

그리고, inode 라는것도 있습니다.(질문하신 분의 경우와는 거리가 멉니다)
(작년 초에 회사에서 파일이 너무많아 생성이 안되더군요.. -_-;; )

언제나 시작

alwaysN00b의 이미지

singlet wrote:
angpoo wrote:

* 한 디렉토리 내의 실질적인 최대 파일 개수는 10000 ~ 15000 (이 이상일 경우 속도 저하가 심각합니다)

ㅋㅋ ~~
회사에 한 디렉토리에 파일이 몇만개 된적이 있었습니다.

ls -al |wc 하고 10분이 넘게 기다렸는데 안나옵니다.. -_-;;

rm -rf * 돌리고 다음날 와도 아직 안끝나 있더군요..

아마 일주일 넘게 rm -rf * 를 근무 끝나는 시간마다 돌렸던 기억이..(무식하게도..)

언제나 시작

nohmad의 이미지

alwaysN00b wrote:
singlet wrote:
angpoo wrote:

* 한 디렉토리 내의 실질적인 최대 파일 개수는 10000 ~ 15000 (이 이상일 경우 속도 저하가 심각합니다)

ㅋㅋ ~~
회사에 한 디렉토리에 파일이 몇만개 된적이 있었습니다.

ls -al |wc 하고 10분이 넘게 기다렸는데 안나옵니다.. -_-;;

rm -rf * 돌리고 다음날 와도 아직 안끝나 있더군요..

아마 일주일 넘게 rm -rf * 를 근무 끝나는 시간마다 돌렸던 기억이..(무식하게도..)

rm -rf * 같은 명령은 실제 커맨드로 인수가 전달될 때 쉘의 인수확장(globbing)에 의해 불필요하게 많은 메모리가 할당되기 때문에, 만일 시리얼한 파일이라면 rm -rf foo1*.ext과 같은 식으로 나눠서 처리하는 것이 훨씬 효율적이더군요.
angpoo의 이미지

singlet wrote:
angpoo wrote:
참고로 말씀드리자면
#define EXT3_LINK_MAX 32000
디렉토리안에 만들 수 있는 서브디렉토리의 한계로 알고 있습니다.
. .. 두개가 필수적으로 만들어지니 32000 - 2개를 만들 수 있습니다.

... 역시 아닙니다;;

말 그대로, 최대로 만들 수 있는 링크의 개수입니다. -_-;; 더 정확히는 hard-link 의 최대 개수지요.


EXT3_LINK_MAX가 하드링크의 한계인건 분명하지만
실질적인 의미로 봤을때 서브디렉토리의 한계라고 봐도 됩니다.
Quote:
커널 소스의 Documentation/filesystems/ext2.txt 내용을 참고하시면 다른 한계도 찾아보실 수 있습니다. 일부 여기 적어보자면-

* 한 디렉토리 내의 최대 서브디렉토리 개수는 32768 개
* 한 디렉토리 내의 이론적인 최대 파일 개수는 130 조 개 이상
* 한 디렉토리 내의 실질적인 최대 파일 개수는 10000 ~ 15000 (이 이상일 경우 속도 저하가 심각합니다)


서브디렉토리 하드링크의 한계에 의해 32000개 밖에 못 만듭니다.
alwaysN00b의 이미지

nohmad wrote:
alwaysN00b wrote:
singlet wrote:
angpoo wrote:

* 한 디렉토리 내의 실질적인 최대 파일 개수는 10000 ~ 15000 (이 이상일 경우 속도 저하가 심각합니다)

ㅋㅋ ~~
회사에 한 디렉토리에 파일이 몇만개 된적이 있었습니다.

ls -al |wc 하고 10분이 넘게 기다렸는데 안나옵니다.. -_-;;

rm -rf * 돌리고 다음날 와도 아직 안끝나 있더군요..

아마 일주일 넘게 rm -rf * 를 근무 끝나는 시간마다 돌렸던 기억이..(무식하게도..)

rm -rf * 같은 명령은 실제 커맨드로 인수가 전달될 때 쉘의 인수확장(globbing)에 의해 불필요하게 많은 메모리가 할당되기 때문에, 만일 시리얼한 파일이라면 rm -rf foo1*.ext과 같은 식으로 나눠서 처리하는 것이 훨씬 효율적이더군요.

nohmad님 글을 읽으니 생각났습니다.
rm -rf * 하니 인수가 너무 많아 실행이 되질 않아 말씀대로
rm -rf foo123* 식으로 처리했습니다. :)

언제나 시작

angpoo의 이미지

alwaysN00b wrote:

nohmad님 글을 읽으니 생각났습니다.
rm -rf * 하니 인수가 너무 많아 실행이 되질 않아 말씀대로
rm -rf foo123* 식으로 처리했습니다. :)

rm -rf * 할꺼면
상위디렉토리에서 rm -rf xxx하면 되지 않나요

simpid의 이미지

이 주제가 여기까지 왔군요.

위에글들 읽다가 저희팀 상황이 생각나서 한줄 씁니다.

윗쪽에 제 글에서 저희 팀 제품이 Tru64, Linux, Windows, hpux, solaris등에서 10000개의 폴더를 만들고... 천만개 이상의 파일이 그 안에 나눠져 들어간다고 했는데....

결국 문제가 터졌습니다.

Tru64에서 볼륨 크기가 500GB일때 1600만개 쯤 들어가니까 심각한 속도 저하가 발생했습니다.(사용 공간 80% 정도) 읽기 성은엔 문제가 없는데.. 쓰기 속도에 문제가 심각합니다.
서버 업체에서 확인하고 엄청난 파일 개수에 놀라더니... 파일 수를 줄여야 할 것 같다고(20~30만개가 적당하다고 하더군요) 볼륨을 2개로 나누자고 하더군요..

그래서 250GB 로 나웠는데... 250GB 짜리 볼륨도 800만개쯤 되니까 심각한 속도 저하고 생기고 있습니다.(사용 공간 80% 정도)

이쯤되니까... 파일 개수보다는 파일 개수와 남은 공간의 복합적인 이유라고 판단되고 있는데...
어째튼 어떻게 풀어가야 할지 서버 업체의 고견(?)이나 기다리고 있는 상황입니다.

Window의 NTFS나 Linux ext2 에서도 안생긴 문제가 Tru64에서만 생겨서 황당한 상황인데... (다른 거래처에 납품한 Tru64는 괜찮습니다.)
서버 업체의 설치 잘못인지(또다른 거래처의 Tru64는 io 버퍼 크기릴 잘못 잡아나서 속도 문제 생긴적 있습니다.) , Tru64의 파일 시스템의 한계인지 확인을 기다리고 있습니다.

hb_kim의 이미지

simpid wrote:
이 주제가 여기까지 왔군요.

위에글들 읽다가 저희팀 상황이 생각나서 한줄 씁니다.

윗쪽에 제 글에서 저희 팀 제품이 Tru64, Linux, Windows, hpux, solaris등에서 10000개의 폴더를 만들고... 천만개 이상의 파일이 그 안에 나눠져 들어간다고 했는데....

결국 문제가 터졌습니다.

Tru64에서 볼륨 크기가 500GB일때 1600만개 쯤 들어가니까 심각한 속도 저하가 발생했습니다.(사용 공간 80% 정도) 읽기 성은엔 문제가 없는데.. 쓰기 속도에 문제가 심각합니다.
서버 업체에서 확인하고 엄청난 파일 개수에 놀라더니... 파일 수를 줄여야 할 것 같다고(20~30만개가 적당하다고 하더군요) 볼륨을 2개로 나누자고 하더군요..

그래서 250GB 로 나웠는데... 250GB 짜리 볼륨도 800만개쯤 되니까 심각한 속도 저하고 생기고 있습니다.(사용 공간 80% 정도)

이쯤되니까... 파일 개수보다는 파일 개수와 남은 공간의 복합적인 이유라고 판단되고 있는데...
어째튼 어떻게 풀어가야 할지 서버 업체의 고견(?)이나 기다리고 있는 상황입니다.

Window의 NTFS나 Linux ext2 에서도 안생긴 문제가 Tru64에서만 생겨서 황당한 상황인데... (다른 거래처에 납품한 Tru64는 괜찮습니다.)
서버 업체의 설치 잘못인지(또다른 거래처의 Tru64는 io 버퍼 크기릴 잘못 잡아나서 속도 문제 생긴적 있습니다.) , Tru64의 파일 시스템의 한계인지 확인을 기다리고 있습니다.

fragment 문제같이 들리는데 하드 용량을 늘려보시는게 어떨까요?

pynoos의 이미지

alwaysN00b wrote:

ls -al |wc 하고 10분이 넘게 기다렸는데 안나옵니다.. -_-;;

파일이 많은 경우에는 -l 은 금물이고 -U 를 넣어 sort도 하지 않아야합니다.

ls -aU

가 그나마 답답한 속을 풀어주죠..

불량청년의 이미지

singlet wrote:
불량청년 wrote:
ext3에선 32000개 이상 못 만들껍니다.

설마 이것을 말씀하시는 것입니까?
#define EXT3_LINK_MAX 32000
이건 파일 개수가 아니라 링크 개수입니다. 실제로 테스트해보면 파일 32000 개 정도는 가뿐히 넘길 수 있음을 알 수 있습니다. 십만개도 만들 수 있던데요. (십만개 제한은 아닙니다. 생각보다 오래 걸려서 중간에 그만 뒀는데 그 때까지 생성한 파일 개수가 십만여개였다는 것일 뿐. 제 시스템에서 돌린 간단한 테스트 프로그램으로는 여기까지 약 15분쯤 걸렸습니다.)

답변을 올리실 때에는 그냥 추측한 내용보다는 되도록이면 실제 결과에 바탕해서 올려주셨으면 합니다. 아니면 최소한 추정이라는 말씀이라도 붙여주시거나요.

제 답변 때문에 삽질이라도 하셨나요? 전 질문하고 답변이라도 달아주시면 틀리던 맞던 무지 고맙던데요. 님은 안그런가봐요?

제가 링크 갯수와 혼동 한것은 인정합니다. 디렉토리 생성 갯수 연관이 있겠군요. 이점은 죄송하게 됐습니다.
회사에서 일하면서 간간히 답변 다는데 이런 소리 들으면 정말 짜증 나는데.. 저만 그런가요?

님의 질문에 꼭! 정답만 달아야 하는 법이 있나요? 그럼 그냥 무시하고 지나갈까요? 지금 이 쓰레드도 보십시요? 얼마나 길어 졌나요? 틀리고 맞고를 떠나서 여러가지 정보가 오가고 있잖습니까?

여기 KLDP이용을 많이 하면 할 수록, 자게에서 놀고 있는 모습을 보면 님같은 분들 때문인것 같다는 생각도 드네요...

PS : 틀린 답변이라도 시너지 효과가 나와서 우리가 생각하지도 못한 쓰레드가 되어 좀 더 좋은 정보(우리가 생각지도 못 한)도 얻을 수 있습니다. 제가 좀 흥분한 면이 보이는군요. 아무튼, 님 나빠요~!

테스트를 ext 파일시스템에서 하시나요? df -i 해보세요. 파티션마다 할당된 i-noe 갯수가 있습니다. 남아 있는 갯수만큼 파일을 만들 수 있습니다.

H/W가 컴퓨터의 심장이라면 S/W는 컴퓨터의 영혼이다!

alwaysN00b의 이미지

angpoo wrote:
alwaysN00b wrote:

nohmad님 글을 읽으니 생각났습니다.
rm -rf * 하니 인수가 너무 많아 실행이 되질 않아 말씀대로
rm -rf foo123* 식으로 처리했습니다. :)

rm -rf * 할꺼면
상위디렉토리에서 rm -rf xxx하면 되지 않나요

아네.. 해봤습니다. 디렉토리도 지워보고 별짓 다했던걸루 기억됩니다.

시간이 너무 오래걸리고 i/o 도 너무커서 시스템에 부하가 심하더군요.

그래서, 결국 rm -rf foo123* 식으로 처리했습니다.

언제나 시작

댓글 달기

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
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.