☰

700,000개의 파일을 동일한 FS 내의 단일 디렉터리로 이동할 때 장치에 남은 공간이 없습니다.

tag-icon • tag-icon find disk-usage mv
700,000개의 파일을 동일한 FS 내의 단일 디렉터리로 이동할 때 장치에 남은 공간이 없습니다.

나는 다음 명령을 사용하여 내 서버에서 엄청난 수의 파일을 찾아 이동합니다.

find SomeDir/ -maxdepth 10 -type f -mtime +90 -exec mv {} SomeDir2/ \;

약 700,000개의 파일을 이동한 후 다음 오류가 발생합니다.

mv: cannot move ‘SomeDir/Dir1/Dir2/Dir3/file.jpg.gz’ to ‘SomeDir2/file.jpg.gz’: No space left on device

df -i다음과 같은 결과가 있습니다.

/dev/sdb1           322125824 144163358 177962466   45% /files

df -h다음과 같은 결과가 있습니다.

/dev/sdb1            4.8T  3.5T  1.1T   78%   /files

/files다른 디렉터리 에서는 모든 작업을 수행하지 않습니다.

파일 시스템은 ext4.

업데이트

제안한대로 나는 달리고 dmesg -Hwx출력은 다음과 같습니다.EXT4-fs warning (device sdb1): ext4_dx_add_entry:2016: Directory index full!

답변1

max_dir_size_kb디렉토리 마운트 시 설정을 초과(또는 기본값 그대로 유지)했을 수 있습니다 .

리눅스 문서:

max_dir_size_kb=n
    This limits the size of the directories so that any
    attempt to expand them beyond the specified limit in
    kilobytes will cause an ENOSPC error. This is useful in
    memory-constrained environments, where a very large
    directory can cause severe performance problems or even
    provoke the Out Of Memory killer. (For example, if there
    is only 512 MB memory available, a 176 MB directory may
    seriously cramp the system's style.)

( ENOSPC오류 메시지로 변환 No space left on device됨 perror)

따라서 마운트 시 해당 옵션이 지정되지 않았는지(또는 매우 큰 숫자로 지정되었는지) 확인하십시오.

또한 참고사항:

  • 한 폴더에 파일이 너무 많으면 좋지 않은 것 같습니다. 대신 관계형 데이터베이스를 원하시나요? 객체 스토리지?
  • 4.8TB: 최신 하드 드라이브에서는 드문 일이 아니지만 솔직히 다음에 이 시대에 무언가를 설정할 때는 LVM과 같은 스토리지 풀을 사용하십시오. 이를 통해 라이브 시스템의 스냅샷과 같은 것을 얻을 수 있습니다.

답변2

새로 얻은 정보로:

따라서 git 태그 v3.10(예: 커널)에서 linux/fs/ext4/namei.c 라인 2007을 읽으면 운이 좋지 않아 파일 시스템을 조정해야 한다고 생각합니다.

tune2fs -O large_dir /dev/sdb1

디렉토리당 더 많은 것을 허용해야 dx_entries하지만 솔직히 저는 그렇게 해본 적이 없습니다. 평소처럼 백업을 해두세요.

백업이 있는지 확인하거나 파일을 동일한 파일 시스템 내에서 이동하는 대신 복사할 새 파일 시스템에 적용하세요. 마치 제가 XFS 팬인 것처럼 보일 수도 있지만(그렇지는 않습니다. 그냥 작동합니다.) 조정되지 않은 ext4가 이 사용 사례에 적합한 파일 시스템인 것처럼 들리지는 않습니다.

관련 정보