성공하지 못한 채 매우 큰 일부 디렉토리를 삭제하려고 했습니다. 다음은 몇 가지 관찰 사항입니다.
# cwd contains the two larger directories
$ ls -lhF
drwxrwxr-x 2 hongxu hongxu 471M Oct 16 18:52 J/
drwxr-xr-x 2 hongxu hongxu 5.8M Oct 16 17:21 u/
# Note that this is the output of `ls` of the directory themselves so they should be *huge*
# J/ seems much larger than u/ (containing more files), so take u/ as an example
$ rm -rf u/
# hang for a very long time, and finally report
rm: traversal failed: u: Bad message
$ cd u/
# can cd into u/ without problems
$ ls -lhF
# hang for a long time; cancel succeeds when I press Ctrl-C
$ rm *
# hang for a long time; cancel fails when I press Ctrl-C
# however there are no process associated with `rm` as reported by `ps aux`
두 디렉토리 모두 대부분 작은 파일을 많이 포함하고 있습니다(각각 10,000개를 넘지 않는 것으로 생각됩니다). 이제 더 많은 디스크 공간을 확보하기 위해 이 두 디렉터리를 삭제해야 합니다. 어떻게 해야 합니까?
업데이트 1:
상당한 시간(>2시간)이 경과했음을 rm -rf u/보여주는 출력을 살펴보십시오 . rm: traversal failed: u: Bad message그래서 문제는 효율성이 아닌 것 같습니다.
업데이트 2:
적용하면 fsck다음과 같이 보고됩니다(양호해 보입니다).
$ sudo fsck -A -y /dev/sda2
fsck from util-linux 2.31.1
fsck.fat 4.1 (2017-01-24)
/dev/sda1: 13 files, 1884/130812 clusters
$ df /dev/sda2
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 244568380 189896000 43628648 82% /
업데이트 3:
관련이 있을 수 있지만 그렇지 않은 경우 이 두 디렉터리( 그것은 중요하지 않습니다!J/및 u/)에는 명령 terminfo으로 생성된 디렉터리가 포함됩니다. 일반 컴파일된 terminfo 파일(예: 내부 디렉터리)과 달리 이러한 파일은 일부 퍼징 기술을 사용하여 생성되므로 "적법한 디렉터리"가 아닐 수 있습니다. "terminfo 파일입니다.tic/lib/terminfo
업데이트 4:
추가 관찰:
$ find u/ -type f | while read f; do echo $f; rm -f $f; done
# hang for a long time, IUsed (`df -i /dev/sda2`) not decreased
$ mkdir emptyfolder && rsync -r --delete emptyfolder/ u/
# hang for a long time, IUsed (`df -i /dev/sda2`) not decreased
$ strace rm -rf u/
execve("/bin/rm", ["rm", "-rf", "u"], 0x7fffffffc550 /* 121 vars */) = 0
brk(NULL) = 0x555555764000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=125128, ...}) = 0
mmap(NULL, 125128, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7fd8000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\34\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=2030544, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffff7fd6000
mmap(NULL, 4131552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffff79e4000
mprotect(0x7ffff7bcb000, 2097152, PROT_NONE) = 0
mmap(0x7ffff7dcb000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0x7ffff7dcb000
mmap(0x7ffff7dd1000, 15072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffff7dd1000
close(3) = 0
arch_prctl(ARCH_SET_FS, 0x7ffff7fd7540) = 0
mprotect(0x7ffff7dcb000, 16384, PROT_READ) = 0
mprotect(0x555555762000, 4096, PROT_READ) = 0
mprotect(0x7ffff7ffc000, 4096, PROT_READ) = 0
munmap(0x7ffff7fd8000, 125128) = 0
brk(NULL) = 0x555555764000
brk(0x555555785000) = 0x555555785000
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1683056, ...}) = 0
mmap(NULL, 1683056, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7e3b000
close(3) = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
lstat("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
newfstatat(AT_FDCWD, "u", {st_mode=S_IFDIR|0755, st_size=6045696, ...}, AT_SYMLINK_NOFOLLOW) = 0
openat(AT_FDCWD, "u", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=6045696, ...}) = 0
fcntl(3, F_GETFL) = 0x38800 (flags O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_NOFOLLOW|O_DIRECTORY)
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
getdents(3, /* 2 entries */, 32768) = 48
getdents(3, /* 1 entries */, 32768) = 24
... (repeated lines)
getdents(3, /* 1 entries */, 32768) = 24
getdents(3strace: Process 5307 detached
<detached ...>
# (manually killed)
$ ls -f1 u/
./
../
../
../
../
... (repeated lines)
../
$ sudo journalctl -ex
Oct 17 16:00:16 CSLRF03AU kernel: JBD2: Spotted dirty metadata buffer (dev = sda2, blocknr = 0). There's a risk of filesystem corruption in case of system crash.
Oct 17 16:00:20 CSLRF03AU kernel: EXT4-fs error: 6971 callbacks suppressed
Oct 17 16:00:20 CSLRF03AU kernel: EXT4-fs error (device sda2): ext4_htree_next_block:948: inode #9789534: block 1020: comm find: Directory index failed checksum
Oct 17 16:00:20 CSLRF03AU kernel: EXT4-fs error (device sda2): ext4_htree_next_block:948: inode #9789534: block 1020: comm zsh: Directory index failed checksum
Oct 17 16:00:20 CSLRF03AU kernel: EXT4-fs error (device sda2): ext4_htree_next_block:948: inode #9789534: block 1020: comm rm: Directory index failed checksum
Oct 17 16:00:20 CSLRF03AU kernel: EXT4-fs error (device sda2): ext4_htree_next_block:948: inode #9789534: block 1020: comm find: Directory index failed checksum
Oct 17 16:00:20 CSLRF03AU kernel: EXT4-fs error (device sda2): ext4_htree_next_block:948: inode #9789534: block 1020: comm rsync: Directory index failed checksum
Oct 17 16:00:20 CSLRF03AU kernel: EXT4-fs error (device sda2): ext4_htree_next_block:948: inode #9789534: block 1020: comm zsh: Directory index failed checksum
Oct 17 16:00:20 CSLRF03AU kernel: EXT4-fs error (device sda2): ext4_htree_next_block:948: inode #9789534: block 1020: comm zsh: Directory index failed checksum
Oct 17 16:00:20 CSLRF03AU kernel: EXT4-fs error (device sda2): ext4_htree_next_block:948: inode #9789534: block 1020: comm rm: Directory index failed checksum
Oct 17 16:00:20 CSLRF03AU kernel: EXT4-fs error (device sda2): ext4_htree_next_block:948: inode #9789534: block 1020: comm find: Directory index failed checksum
Oct 17 16:00:20 CSLRF03AU kernel: EXT4-fs error (device sda2): ext4_htree_next_block:948: inode #9789534: block 1020: comm find: Directory index failed checksum
# #9789534 is the inode of `u/` as reported by `ls -i`
따라서 파일 시스템이 손상되어야 합니다. 하지만 다시 시작해도 작동하지 않습니다. :(
답변1
좋아, 마침내 문제를 해결했습니다. 이는 ls디스플레이 오류와 기타 유틸리티의 오작동을 일으키는 파일 시스템 오류로 인해 발생합니다 .
죄송합니다. 질문 제목이 오해의 소지가 있습니다. (실제로 많은 파일이 있지만 u/디렉토리는별로 크지 않은).
손상된 파일 시스템이 있었기 때문에 라이브 USB를 사용하여 문제를 해결했습니다 /. 수정 사항은 손상된 디스크가 있는 곳에 적용하는 것뿐이었습니다 sudo fsck -cfk /dev/sda2.dev/sda2
답변2
를 사용하여 대용량 파일을 삭제할 수 없습니다 rm. 넌 할 수있어
find u/ -type f -print0 | xargs -r -0 rm -f
모든 파일을 삭제하려면 파일만 삭제됩니다.
find u/ -print0 | xargs -r -0 rm -rf
시스템에 다음 옵션이 있는 경우 이 옵션을 사용할 수 있습니다 --delete.find
find u/ -type f --delete
또는 펑키한 방식으로 rsync:
mkdir emptyfolder
rsync -r --delete emptyfolder/ u/
rsyncrm일부 검사를 우회하므로 콘텐츠를 삭제하는 것보다 훨씬 빠릅니다 .
답변3
find /u -type f | while read f; do rm -f $f; done
시간이 좀 걸리지만 시도해 볼 수 있습니다 . 어떤 이유로 다른 방법이 실패하더라도 bash의 루프는 완벽하게 작동합니다.