分区失败后磁盘容量显示异常,寻求无数据丢失的修复方案
分区失败后磁盘容量显示异常,寻求无数据丢失的修复方案
问题描述
我正在使用Ubuntu 20.04,想通过Live USB对硬盘进行分区操作,但过程中出了问题导致电脑崩溃。重启后发现磁盘显示已使用70%,但这明显不符合实际情况。有没有办法不格式化整个硬盘、不丢失数据的前提下修复这个问题?
补充信息
sudo parted -l 输出
Model: Sony Storage Media (scsi) Disk /dev/sda: 31,0GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 31,0GB 31,0GB Ventoy msftdata 2 31,0GB 31,0GB 33,6MB fat16 VTOYEFI hidden, msftdata Model: Generic Flash Disk (scsi) Disk /dev/sdb: 15,7GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 32,8kB 3822MB 3822MB ISO9660 hidden, msftdata 2 3822MB 3826MB 4350kB Appended2 boot, esp 3 3826MB 3827MB 307kB Gap1 hidden, msftdata 4 3827MB 15,7GB 11,9GB ext4 Model: PC611 NVMe SK hynix 1TB (nvme) Disk /dev/nvme0n1: 1024GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 829MB 828MB fat32 EFI system partition boot, esp 2 829MB 6198MB 5369MB fat32 Basic data partition msftres 3 6198MB 1024GB 1018GB ext4
lsblk -f 输出
NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT loop0 squashfs 0 100% /snap/bare/5 loop1 squashfs 0 100% /snap/chromium/2271 loop2 squashfs 0 100% /snap/code/117 loop3 squashfs 0 100% /snap/chromium/2295 loop4 squashfs 0 100% /snap/core22/504 loop5 squashfs 0 100% /snap/core/14399 loop6 squashfs 0 100% /snap/core18/2667 loop7 squashfs 0 100% /snap/cups/836 loop8 squashfs 0 100% /snap/core20/1778 loop9 squashfs 0 100% /snap/core22/484 loop10 squashfs 0 100% /snap/core/14447 loop11 squashfs 0 100% /snap/core20/1822 loop12 squashfs 0 100% /snap/code/118 loop13 squashfs 0 100% /snap/core18/2679 loop14 squashfs 0 100% /snap/gnome-3-26-1604/102 loop15 squashfs 0 100% /snap/gnome-3-26-1604/104 loop16 squashfs 0 100% /snap/cups/872 loop17 squashfs 0 100% /snap/gnome-3-28-1804/161 loop18 squashfs 0 100% /snap/gnome-3-28-1804/145 loop19 squashfs 0 100% /snap/gnome-3-34-1804/77 loop20 squashfs 0 100% /snap/gnome-3-34-1804/72 loop21 squashfs 0 100% /snap/gnome-3-38-2004/115 loop22 squashfs 0 100% /snap/gnome-3-38-2004/119 loop23 squashfs 0 100% /snap/gnome-42-2204/44 loop24 squashfs 0 100% /snap/gnome-42-2204/56 loop25 squashfs 0 100% /snap/gnome-system-monitor/178 loop26 squashfs 0 100% /snap/gnome-system-monitor/181 loop27 squashfs 0 100% /snap/gtk-common-themes/1534 loop28 squashfs 0 100% /snap/pdftk/9 loop29 squashfs 0 100% /snap/gtk-common-themes/1535 loop30 squashfs 0 100% /snap/snap-store/638 loop31 squashfs 0 100% /snap/snap-store/599 loop32 squashfs 0 100% /snap/spotify/58 loop33 squashfs 0 100% /snap/spotify/60 loop34 squashfs 0 100% /snap/walc/19 loop35 squashfs 0 100% /snap/xournalpp/69 loop36 squashfs 0 100% /snap/xournalpp/61 sda ├─sda1 exfat Ventoy D558-0641 23,3G 19% /media/tom/Ventoy └─sda2 vfat VTOYEFI B228-8EFB 7,8M 76% /media/tom/VTOYEFI sdb iso9660 Ubuntu 22.04.1 LTS amd64 2022-08-10-16-21-45-00 ├─sdb1 iso9660 Ubuntu 22.04.1 LTS amd64 2022-08-10-16-21-45-00 0 100% /media/tom/Ubuntu 22.04.1 LTS amd64 ├─sdb2 vfat ESP 8D6C-A9F8 ├─sdb3 └─sdb4 ext4 writable cb3577c8-f301-4e8d-89c4-9073a372313f 10,2G 0% /media/tom/writable nvme0n1 ├─nvme0n1p1 vfat ESP 108E-5584 728,9M 7% /boot/efi ├─nvme0n1p2 vfat OS 6EC6-83CF └─nvme0n1p3 ext4 UBUNTU 05d97eaa-d7b7-4f80-98e1-dca239de0c03 195,3G 47% /
解决方案
先看你提供的命令输出,你的1TB NVMe硬盘(/dev/nvme0n1)分区表其实是正常的:根分区nvme0n1p3显示已用47%,和你说的“70%已用”大概率是系统缓存、临时文件或者文件系统统计异常导致的。下面是几个安全的修复步骤,不会丢失数据:
第一步:清理系统缓存与临时文件
有时候系统缓存会占用大量内存并被误算成磁盘占用,先清理试试:- 执行命令清理缓存:
sudo sync && sudo sysctl -w vm.drop_caches=3 - 用图形化工具Disk Usage Analyzer扫描根目录,找出可能存在的大临时文件/日志;如果习惯命令行,可以先安装
ncdu:sudo apt install ncdu,然后运行ncdu /可视化查看磁盘占用情况,删除无用的大文件。
- 执行命令清理缓存:
第二步:离线检查修复ext4文件系统
分区崩溃很可能导致文件系统出现一致性错误,需要在未挂载的状态下修复:- 重启进入你之前用的Ubuntu 22.04 Live USB系统
- 先确认根分区
/dev/nvme0n1p3没被挂载:执行sudo umount /dev/nvme0n1p3,如果提示已挂载,找到对应的挂载点卸载即可 - 执行文件系统检查修复:
sudo e2fsck -f /dev/nvme0n1p3,过程中如果出现确认提示,按y同意修复即可。
第三步:更新磁盘使用统计
系统的磁盘统计可能因为异常操作滞后,手动更新:- 执行
sudo updatedb更新系统文件索引 - 再用
df -h /查看最新的磁盘占用,或者重新打开Disk Usage Analyzer扫描。
- 执行
另外注意你的nvme0n1p2分区是fat32格式但未挂载,如果之前误操作过这个分区,也可以挂载后检查它的占用情况,但核心问题应该还是根分区的统计异常或文件系统错误。
最后提醒:操作前建议把重要数据备份到外部存储(比如你的Ventoy USB盘),虽然这些操作都是安全的,但谨慎一点总是没错的。
备注:内容来源于stack exchange,提问作者Tom
相关产品推荐
相关产品推荐

