Saya mengalami kesalahan I/O pada partisi hard drive eksternal sdb4 (biasanya mountpoint adalah /run/media/yan/data).
Partisi itu tidak responsif, tidak dapat diakses dan menolak untuk di-unmount. Saya tidak tahu apa yang harus dilakukan tetapi mencabut disk dan memasangnya kembali. Setelah itu saya mengalami kesalahan pada fs-nya, jadi saya menjalankan fsck:
sudo e2fsck /dev/sdb4 -y -v
Itu meminta banyak perbaikan (ribuan) tetapi karena data tidak penting pada disk itu, saya menjalankannya dengan -y.
data contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
# Fixed invalid inode numbers, incorrect filetypes, cleared links, deleted/unused inodes
Pass 3: Checking directory connectivity
# Connected unconnected directory inodes to /lost+found
Pass 4: Checking reference counts
#Fix inodes ref count, connected unattached inode to /lost+found
Pass 5: Checking group summary information
# Fix block bitmap differences, blocks count wrong for group
# Fix inode bitmap differences, directories count wrong for group, free inodes count wrong for group
data: ***** FILE SYSTEM WAS MODIFIED *****
72955 inodes used (0.14%, out of 51200000)
2390 non-contiguous files (3.3%)
17 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 72264/636/1
186984621 blocks used (91.30%, out of 204800000)
0 bad blocks
34 large files
70447 regular files
2453 directories
0 character device files
0 block device files
0 fifos
4294966642 links
46 symbolic links (46 fast symbolic links)
0 sockets
------------
71063 files
Jadi jika saya mengerti dengan benar, fsck berhasil menyelamatkan 70k file, jadi sebagian besar file sejak saya memiliki 75-80k file pada disk itu. Masalahnya hanya 20k file yang muncul di ‘/run/media/yan/data/lost+found’, dan hanya 24k di seluruh partisi.
[[email protected] ~]$ find /run/media/yan/data/lost+found | wc -l
19786
[[email protected] ~]$ find /run/media/yan/data | wc -l
23691
Saya memutar ulang fsck tetapi dia memberi tahu saya bahwa partisi tersebut jelas (dan memiliki 74k file?)
[[email protected] ~]$ sudo fsck /dev/sdb4
fsck from util-linux 2.28
e2fsck 1.42.13 (17-May-2015)
data: clean, 74200/51200000 files, 186685980/204800000 blocks[/cpp]
Saya juga memiliki penggunaan disk yang sangat berbeda menurut df dan du (saya tahu pasti ada perbedaan, tetapi di sini tampaknya terlalu besar untuk menjadi normal):
[[email protected] ~]$ df -h /run/media/yan/data
Filesystem Size Used Avail Use% Mounted on
/dev/sdb4 769G 700G 31G 96% /run/media/yan/data
[[email protected] ~]$ du -sh /run/media/yan/data
586G /run/media/yan/data
Saya kira masih ada data yang dipulihkan yang tidak dapat saya akses.
Pertanyaan saya adalah :
1) Apakah mungkin file yang dipulihkan oleh fsck tidak ditempatkan di lost+found ? Kalau begitu, di mana mereka?
2) Apakah ada cara untuk mendapatkan kembali file yang hilang itu?
3) Jika tidak, bagaimana cara mengosongkan ruang ini?
EDIT:
Saya mencoba versi e2fsck yang lebih baru atas rekomendasi sourcejedi:
[[email protected] build]$ sudo ./e2fsck/e2fsck -f /dev/sdb4
e2fsck 1.43.3 (04-Sep-2016)
Pass 1: Checking inodes, blocks, and sizes
Inode 40501578 extent tree (at level 2) could be narrower. Fix<y>? yes
Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
data: ***** FILE SYSTEM WAS MODIFIED *****
data: 74200/51200000 files (3.2% non-contiguous), 186685964/204800000 blocks
Itu tidak banyak membantu, lost+found masih memiliki jumlah dan ukuran file yang sama.
Terkait:Bagaimana cara mendapatkan deskripsi opsi `shopt` yang tersedia?Jawaban yang Diterima:
saya juga melihat jumlah tautan sangat mencurigakan (hampir 2^32).
Anda dapat mencoba e2fsck yang lebih baru, dan/atau melaporkan bug. ini pasti bug.
memindai perangkat/partisi dengan photorec
mungkin memulihkan lebih banyak file, di mana formatnya didukung dan mereka bersebelahan. karena FS Anda cukup penuh, banyak file yang tidak bersebelahan. photorec
tidak memulihkan nama file atau direktori. (mis. jika itu mp3, Anda dapat menggunakan sesuatu seperti picard
untuk menerapkan nama file dari metadata mp3 alias tag ID3). catatan photorec
membutuhkan ruang kosong di sistem file lain, untuk memulihkan semua file.