많은 대용량 파일을 삭제 한 후 여유 공간이 크게 지연됩니다

어제 집 / 미디어 서버에서 71GB의 파일을 삭제했습니다.
여유 공간 이전 : 117GB
여유 공간 : 126GB

따라서 71GB의 추가 여유 공간 대신 ​​9GB 만 사용했습니다. 파일이 열려 있지 않은지 다시 확인했으며 실제로 71GB를 삭제했으며 여유 공간이 실제로 9GB 만 증가했습니다.

또한 동기화를 시도했지만 효과가 없습니다.

이것이 처음이 아닙니다. 사실, 나는 몇 년 이래로이 행동을보고 있습니다. 먼저 ext3에서, 이제 ext4에서.
이 경우 파일 시스템을 마운트 해제 한 후 다시 마운트하여 여유 공간을 확보 할 수 있습니다. 이 경우 마운트 해제에는 거의 시간이 아닌 최대 2 분이 걸립니다.

요즘에는 비디오 레코더 소프트웨어, 가족 용 자체 클라우드 서버 및 지금까지 없었던 몇 가지 추가 서비스로 인해 파일 시스템이 영구적으로 바쁘기 때문에 파일 시스템을 쉽게 마운트 해제했다가 다시 마운트 할 수 없습니다. 그리고 밤에 3시에 일어나서 마운트를 해제하고 다시 마운트하고 싶지 않습니다.

아니요, 'at'유틸리티는 서비스 중 하나가 재개 불가능한 장기 실행 작업을 수행하므로 종료 할 수있는 좋은 순간, 즉 작업이 막 완료된 상태를 찾기 위해 수동 상태 확인이 필요하기 때문에 수행되지 않습니다.

그러나 오늘 아침, 나는 공간이 밤새 비워 졌다는 것을 알아 차렸다. 어떤 종류의 정리가있는 것처럼 나에게 보입니다. 이것은 마운트를 해제 할 때 추가 시간이 걸리는 것과 같습니다.

지금까지 많은 양의 데이터를 삭제할 때만이 동작이 나타났습니다. 다른 한편으로, 나는 그것이 정기적으로 발생하고 그 차이가 너무나 눈에 띄지 않는지 확실하지 않습니다.

파일 시스템은 루트 ( mkfs -m 0) 용으로 0 %를 예약하여 작성되었습니다 . 에 따르면 fsck -f, 파일 시스템이 손상되지 (I이 항상 마운트 해제하고 다시 마운트 사이하고있어), 테스트를 확장 SMART 진단에 따라, 하드웨어도 OK입니다.

[편집하다]

tune2fs 1.42 (29-Nov-2011)  
Filesystem volume name:   bigdata  
Last mounted on:          /bigdata  
Filesystem UUID:          6aebd17a-e064-41dc-9c68-c9a3acbe4f66  
Filesystem magic number:  0xEF53  
Filesystem revision #:    1 (dynamic)  
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize  
Filesystem flags:         signed_directory_hash   
Default mount options:    user_xattr acl  
Filesystem state:         clean  
Errors behavior:          Continue  
Filesystem OS type:       Linux  
Inode count:              121413632  
Block count:              485645568  
Reserved block count:     0  
Free blocks:              29081276  
Free inodes:              121382378  
First block:              0  
Block size:               4096  
Fragment size:            4096  
Reserved GDT blocks:      908  
Blocks per group:         32768  
Fragments per group:      32768  
Inodes per group:         8192  
Inode blocks per group:   512  
Flex block group size:    16  
Filesystem created:       Tue Dec 25 23:42:35 2012  
Last mount time:          Fri Jan  3 17:37:36 2014  
Last write time:          Fri Jan  3 17:37:36 2014  
Mount count:              37  
Maximum mount count:      -1  
Last checked:             Thu Apr 18 17:03:40 2013  
Check interval:           0 (<none>)  
Lifetime writes:          14 TB  
Reserved blocks uid:      0 (user root)  
Reserved blocks gid:      0 (group root)  
First inode:              11  
Inode size:           256  
Required extra isize:     28  
Desired extra isize:      28  
Journal inode:            8  
Default directory hash:   half_md4  
Directory Hash Seed:      be2b977e-5127-4843-9123-fe33b6d7b573  
Journal backup:           inode blocks  

[/편집하다]

그래서 여기 두 가지 질문이 있습니다.

1. 여기서 무슨 일이 일어나고 있습니까? umount에서 여유 공간을 확보하거나 즉시 삭제하지 않고 지연되는 이유는 무엇입니까?
2. 뭔가가 나는 공간을 확보 트리거 할 수 있나요 지금 마운트 해제하고 다시 마운트하지 않고?

상호 작용할 수있는 두 가지 요소가 있습니다.

• Windows와 달리 열려있는 파일을 삭제할 수 있습니다. 스트리밍중인 동영상을 삭제하면 디렉토리에서 제거되지만 스트리밍 프로그램이 닫힐 때까지 파일로 계속 존재합니다. 스트리밍 소프트웨어가 닫으면 공간이 해제됩니다. 이 fuser -m명령은 열린 파일이있는 프로세스의 프로세스 ID를 찾는 데 사용할 수 있습니다. 일부 프로그램은 파일이 완료되면 즉시 파일을 닫지 않을 수 있습니다.

• 이들은 모두 저널 파일 시스템입니다. 변경 사항은 저널에 기록 된 다음 커밋됩니다. 변경 사항을 커밋하는 데 시간이 걸릴 수 있습니다. 운영 체제는 종종 디스크 변경 사항을 캐시하고 정기적으로 디스크 변경 사항을 커밋합니다. sync명령을 실행하면 보류중인 변경 사항을 디스크에 플러시해야합니다. sync옵션을 사용 하여 디스크를 마운트하면 디스크 속도가 향상되지만 디스크가 더 열심히 작동합니다.