儘管有足夠的磁碟空間和 inode 可用,但 Linux 中的裝置上沒有剩餘空間

儘管有足夠的磁碟空間和 inode 可用,但 Linux 中的裝置上沒有剩餘空間

我在使用複製大量文件時遇到了這個問題焦油 -cf - * | (cd ../bar; tar -xf - );

我確實搜尋了這個問題,發現了以下建議,但沒有一個對我有用。即使重新啟動後,此問題仍然存在。

這個問題的一個特點是目標磁碟只是 NTFS 中的資料磁碟,因為我使用的是雙重啟動(ubuntu 20.04 和 Windows 10)。所以,我嘗試使用修復它查克德斯克在 Windows 10 中(請參閱下面的#6),但沒有多大幫助。在 Windows 10 中啟動時我也無法將文件複製到磁碟中,但看到一條不同的消息說“碎片太多”,因此我嘗試使用 Windows 工具對磁碟進行碎片整理,但優化沒有繼續。我不認為「太碎片化」是真正的問題,因為 15T 空間只使用了 2T,而且磁碟才使用兩個月。

有人可以告訴我可以進一步嘗試什麼嗎?非常感謝您事先提供的專業知識!

編輯: 跑步中焦油 -cf - * | (cd ../bar; tar -xf - );,我猜發生了一些溢出,這可能損壞了一些關鍵的東西。它可能與 Ubuntu 20.04 中的某些環境參數有關,但了解可能損壞的內容以及發生這種情況的原因超出了我對 Linux / Ubuntu 的理解

  1. 檢查磁碟空間 <- 有足夠的可用空間(有問題的磁碟是/mnt/e,倒數第二個) df-h
Filesystem      Size  Used Avail Use% Mounted on
udev            252G     0  252G   0% /dev
tmpfs            51G   32M   51G   1% /run
/dev/nvme0n1p2  1.8T  828G  912G  48% /
tmpfs           252G   15M  252G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           252G     0  252G   0% /sys/fs/cgroup
/dev/loop0      128K  128K     0 100% /snap/bare/5
/dev/loop1       56M   56M     0 100% /snap/core18/2246
/dev/loop2       62M   62M     0 100% /snap/core20/1169
/dev/loop3      219M  219M     0 100% /snap/gnome-3-34-1804/72
/dev/loop5       56M   56M     0 100% /snap/core18/2128
/dev/loop4       66M   66M     0 100% /snap/gtk-common-themes/1519
/dev/loop6      9.5M  9.5M     0 100% /snap/htop/3233
/dev/nvme0n1p1  511M  5.3M  506M   2% /boot/efi
/dev/nvme1n1p3  1.9T  1.2T  665G  65% /mnt/c
/dev/loop7       33M   33M     0 100% /snap/snapd/13640
/dev/loop8       51M   51M     0 100% /snap/snap-store/547
/dev/loop9       33M   33M     0 100% /snap/snapd/13270
/dev/loop10      66M   66M     0 100% /snap/gtk-common-themes/1515
tmpfs            51G   16K   51G   1% /run/user/125
/dev/sda2        15T   12T  3.3T  78% /mnt/z
/dev/sdb2        15T  2.0T   13T  14% /mnt/e
tmpfs            51G   36K   51G   1% /run/user/1000
  1. inode 的使用率 <- 1% 用於/mnt/e,df-i
Filesystem          Inodes    IUsed       IFree IUse% Mounted on
udev              65989773     1100    65988673    1% /dev
tmpfs             65997179     8821    65988358    1% /run
/dev/nvme0n1p2   122068992  1554395   120514597    2% /
tmpfs             65997179       40    65997139    1% /dev/shm
tmpfs             65997179        5    65997174    1% /run/lock
tmpfs             65997179       18    65997161    1% /sys/fs/cgroup
/dev/loop0              29       29           0  100% /snap/bare/5
/dev/loop1           10833    10833           0  100% /snap/core18/2246
/dev/loop2           11732    11732           0  100% /snap/core20/1169
/dev/loop3           18500    18500           0  100% /snap/gnome-3-34-1804/72
/dev/loop5           10803    10803           0  100% /snap/core18/2128
/dev/loop4           65095    65095           0  100% /snap/gtk-common-themes/1519
/dev/loop6            3605     3605           0  100% /snap/htop/3233
/dev/nvme0n1p1           0        0           0     - /boot/efi
/dev/nvme1n1p3   698250164  1718509   696531655    1% /mnt/c
/dev/loop7             479      479           0  100% /snap/snapd/13640
/dev/loop8           15841    15841           0  100% /snap/snap-store/547
/dev/loop9             474      474           0  100% /snap/snapd/13270
/dev/loop10          64986    64986           0  100% /snap/gtk-common-themes/1515
tmpfs             65997179       45    65997134    1% /run/user/125
/dev/sda2       3505524112    20634  3505503478    1% /mnt/z
/dev/sdb2      13549630048  3278197 13546351851    1% /mnt/e
tmpfs             65997179       94    65997085    1% /run/user/1000
  1. 磁碟/檔案權限問題 <- 不是問題

  2. 增加inotify.max_user_watches。原來是65536,增加到524288,但沒有幫助

  3. 檢查 du -h 和 df -h 傳回的大小。兩者都是一樣的

  4. 磁碟可能已損壞 <- Windows chkdsk 發現一個不相關的孤立文件,該文件已修復。在第二次 chkdsk 運行時,Windows 中沒有發現問題, chkdsk E:/f

Stage 2: Examining file name linkage ... 
Deleted invalid filename Refinitiv\References (2BE9F9) in directory 5.
File 2BE9F9 has been orphaned since all its filenames were invalid
Windows will recover the file in the orphan recovery phase.
Correcting minor file name errors in file 2BE9F9.
Deleting index entry Refinitiv\References in index $I30 of file 5.
  6 reparse records processed.
  3630180 index entries processed.
Index verification completed.
 Phase duration (Index verification): 14.18 minutes.
CHKDSK is scanning unindexed files for reconnect to their original directory.
  1 unindexed files scanned.
  0 unindexed files recovered to original directory.
 Phase duration (Orphan reconnection): 0.00 milliseconds.
CHKDSK is recovering remaining unindexed files.
  1 unindexed files recovered to lost and found.
    Lost and found is located at \found.000
 Phase duration (Orphan recovery to lost and found): 0.00 milliseconds.
  6 reparse records processed.
 Phase duration (Reparse point and Object ID verification): 8.49 milliseconds.
  1. lsof/ | grep "deleted" --> 沒有這樣的檔案或目錄並出現以下警告
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/125/gvfs Output information may be incomplete. 
lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing Output information may be incomplete.

答案1

在 Windows 10 中啟動時我也無法將檔案複製到磁碟中,

這表示您的目標檔案系統已經嚴重損壞,甚至 Windows 都無法使用它。如果 Windows 的磁碟檢查無法修復它:祝你好運!您應該盡可能從 /mnt/e 到某些備份介質,並使用 Windows 格式化該磁碟區。

相關內容