如何恢復文件系統和物理大小不匹配
我試圖縮小我的主分區。為此，我關注了這篇 ArchWiki文章。據此，我首先使用調整我的文件系統的
resize2fs大小，然後使用調整我的物理設備的大小parted。在resize2fs參數中，我將我的預期大小指定為XG，調整大小後，它報告新大小為Y (4k blocks)。根據這些資訊，我計算出我的分區大小為**(Y * 4) KiB**，當使用 parted 調整物理分區大小時，我使用了這個大小。但實際上它是**(Y * 4) KB**。所以現在文件系統的總塊數高於物理設備的總塊數。在
resize2fs手冊頁中指出，如果未指定大小，它將佔用設備的整個空間。因此，為了解決這個問題，我resize2fs再次執行，以使其 fs 大小與物理大小相匹配。但它給出了以下錯誤：resize2fs 1.45.6 (20-Mar-2020) Resizing the filesystem on /dev/sda3 to 159907584 (4k) blocks. resize2fs: Can't read a block bitmap while trying to resize /dev/sda3 Please run 'e2fsck -fy /dev/sda3' to fix the filesystem after the aborted resize operation.但是當我發出
e2fsck它報告不匹配並建議中止時。所以，現在我陷入了一個循環：e2fsck 1.45.6 (20-Mar-2020) The filesystem size (according to the superblock) is 186122240 blocks The physical size of the device is 159907584 blocks Either the superblock or the partition table is likely to be corrupt! Abort<y>?有什麼辦法可以從中恢復嗎？掛載和訪問分區以便進行備份是否安全？
謝謝！
從您所寫的內容來看，您意外地縮小了一個小於其包含的文件系統的分區。就其本身而言，這不應該失去任何數據，但之後您可能執行的幾乎所有操作都可能
$$ have $$. 這肯定包括
resize2fs,e2fsck和mount。看來您很幸運，因為您執行的兩個命令都檢測到了問題併中止了。 最大的問題是你對通過縮小分區創建的額外空間做了什麼嗎？如果你這樣做了，如果你製作了一個額外的分區並對其進行了格式化，那麼你可能已經損壞了無法修復的數據。如果沒有，那麼你可能會沒事。要解決眼前的問題，您必須使用諸如
parted將分區增加到其原始大小的工具。如果您已經沒有對該可用空間進行任何操作，那麼您的數據應該就在您離開的地方。這將解決眼前的問題，您可以使用它e2fsck來仔細檢查。 如果它給您與第一次類似的警告，請中止。問題的根本原因是
resize2fs在使用parted. 這是將任何文件數據移出您要從分區中刪除的空間所必需的。我注意到您正確引用的 wiki表明您應該在…中指定大小
resize2fs。…請對單位非常小心，並花時間了解您輸入的數字。ext2/3/4 中的 4k 塊意味著 4096 字節。在其他地方，“塊”一詞可能意味著完全不同的東西。還有許多分區程序，包括
parted區分 KB、MB 和 KiB、MiB。確保您知道您打算使用哪些單位：
- KB = 1,000 MB = 1,000,000
- KiB = 1,024 MiB = 1,048,576