어제 집 / 미디어 서버에서 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. 뭔가가 나는 공간을 확보 트리거 할 수 있나요 지금 마운트 해제하고 다시 마운트하지 않고?

답변