Điểm:1

Không thể tìm thấy nội dung chiếm quá nhiều dung lượng

lá cờ cn

Tôi đang gặp sự cố khi cố gắng tìm ra thứ chiếm quá nhiều dung lượng trên một trong các ổ đĩa của mình, cụ thể là /dev/sdc1 được gắn trên /

Như bạn có thể thấy bên dưới 862G đang được sử dụng, tôi đã sử dụng tất cả các phương pháp mà tôi có thể nghĩ ra để tìm các thư mục lớn nhất (không bao gồm sdb1 và sda1) và tất cả những gì tôi có thể tìm thấy là 19G trên thư mục siêu dữ liệu Plex của mình. Vậy đó... Tôi cần tìm ra cách để tìm ra chính xác thứ đang chiếm dung lượng này vì điều này chỉ mới xảy ra trong vài ngày qua sau khi sdb1 bị ngắt kết nối do mất điện nên nó "liên kết" hay chuyển file qua đó? Mặc dù tôi dường như không thể tìm thấy bất kỳ... và hoàn toàn không biết làm thế nào để đi từ đây...

Tôi đang chạy Ubuntu 20.04.3 LTS trên Odroid N2+ không đầu

Kích thước hệ thống tệp được sử dụng Sẵn có Sử dụng % Được gắn trên
udev 1.4G 0 1.4G 0%/dev
tmpfs 370M 6,3M 364M 2%/lần chạy
/dev/sdc1 938G 862G 29G 97%/
tmpfs 1,9G 0 1,9G 0%/dev/shm
tmpfs 5,0M 4,0K 5,0M 1%/chạy/khóa
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
tmpfs 1,9G 4,0K 1,9G 1%/tmp
/dev/mmcblk1p1 29G 10G 18G 37% /media/mmcboot
/dev/sdb1 1.8T 1.6T 108G 94%/mnt/hdd2
/dev/sda1 7.3T 6.8T 504G 94%/mnt/hdd
/dev/zram1 49M 4,6M 41M 11%/var/log
tmpfs 370M 0 370M 0%/chạy/người dùng/1000

Kết quả tìm kiếm của tôi bằng cách sử dụng

sudo du -hs .[^.]* | sắp xếp -rh | đầu -30

19G .config
12M .docker
56K .bash_history
4.0K .viminfo
4.0K .hồ sơ
4.0K .cache
4.0K .bashrc
4.0K .bash_logout
0 .Xauthority
0 .sudo_as_admin_successful

tôi đã thử ncdu cũng như nó cho thấy:

   19.0 GiB [##########] /.config 11.5 MiB [ ] /.docker
   56,0 KiB [ ] .bash_history
e 4.0 KiB [ ] /Tải xuống
    4.0 KiB [ ] /.cache
    4.0 KiB [ ] .bashrc
    4.0 KiB [ ] .viminfo
    4.0 KiB [ ] .profile
    4.0 KiB [ ] .bash_logout
    0,0 B [ ] .sudo_as_admin_successful
    0,0 B [ ].Xauthority

sử dụng sudo du -xh -d 3 / | sắp xếp -h -r | egrep -v '*K|*M'

sản lượng

109 gam /
84G /mnt/tải xuống
84G / phút
83G /mnt/tải xuống/nzbget
19G /home/sptz/.config
19G /nhà/sptz
19G/nhà
4,5G /bình
4.3G /var/lib
4.1G /var/lib/docker
1,5G /usr

Tôi đoán ở trên không bao gồm /mnt/hdd và /mnt/hdd2 hay còn gọi là sdb1 và sda1 phải không?

Bất kỳ ý tưởng?

Cảm ơn!

lá cờ uz
Jos
Giả sử một hệ thống tệp (giả sử `/dev/sdb1`) phải được gắn trên `/dev/sdc1`, với điểm gắn `/mnt/hdd`. Tuy nhiên, giả sử rằng quá trình gắn kết bị lỗi. Nếu một số quy trình vẫn ghi dữ liệu vào `/mnt/hdd`, nó sẽ kết thúc trên `/dev/sdc1`. Nếu sau đó bạn gắn `/dev/sdb1` thành công, dữ liệu này sẽ không thể truy cập được (vì `/mnt/hdd` hiện trỏ đến hệ thống tệp khác) nhưng dữ liệu này vẫn chiếm dung lượng. Đây có thể là những gì đã xảy ra trong trường hợp của bạn?
N0rbert avatar
lá cờ zw
Gắn đĩa này từ hệ thống khác và chạy `ncdu` trên đó.
Sptz87 avatar
lá cờ cn
Jos, tôi tin rằng đây chính xác là những gì đã xảy ra. Không biết làm thế nào để sửa nó bây giờ :/
walttheboss avatar
lá cờ es
Vui lòng chỉnh sửa câu hỏi của bạn bằng cách thêm phân phối bạn đang sử dụng. Ví dụ Ubuntu 20.04
Điểm:1
lá cờ vn

Bạn tự nói với chính mình: "sdb1 was unmount do cúp điện". Điều này có thể có nghĩa là trong thời gian này, một số dữ liệu đã được ghi vào /mnt/hdd2 trong khi sdb1 không được gắn kết.

Ngắt kết nối các thiết bị này:

/dev/sdb1 1.8T 1.6T 108G 94%/mnt/hdd2
/dev/sda1 7.3T 6.8T 504G 94%/mnt/hdd

Và sau đó kiểm tra các thư mục để tìm dữ liệu (bắt đầu bằng /mnt/hdd2) - Tôi tin rằng sẽ có khoảng ~750 GB dữ liệu ở đây.

Tôi đoán là dữ liệu đã được ghi vào một trong những thư mục này, nơi đĩa không được gắn vào. Dữ liệu này hiện "biến mất" khi các ổ đĩa được kết nối lại.

Đây chỉ là phỏng đoán đủ điều kiện, nhưng 99% trường hợp dữ liệu biến mất một cách bí ẩn, đây dường như là vấn đề.

Sptz87 avatar
lá cờ cn
Đây chính là nó! Tôi đã ngắt kết nối cả hai thiết bị đó và nó ở đó. 700GB dữ liệu trong mnt/hdd. Tôi hiểu logic đằng sau nó nhưng điều này có nghĩa là nếu sda1 được gắn kết thì thực sự không thể truy cập các tệp "ẩn" đó?
Artur Meinild avatar
lá cờ vn
Đúng. (------------------)
HuHa avatar
lá cờ es
@Sptz87: Có một cách, nhưng nó không dành cho người yếu tim: https://github.com/shundhammer/qdirstat/blob/master/doc/Shadowed-by-Mount.md
Artur Meinild avatar
lá cờ vn
Có, tôi tin rằng việc ngắt kết nối đơn giản, điều tra và kể lại là đủ trong hầu hết các trường hợp.
Điểm:0
lá cờ es

Cài đặt qdirstat Chạy nó với quyền root bằng cách khởi chạy nó từ Terminal/Konsole.

sudo qdirstat

Chọn thư mục gốc hoặc nhà và sau đó chạy nó. Nó sẽ tìm thấy những thứ ở đâu.

Sptz87 avatar
lá cờ cn
Thật không may, đó là một phần mềm đồ họa. Máy chủ của tôi không có đầu và không có cách nào kết nối màn hình với nó :/ Phải có giải pháp thay thế
lá cờ cn
@ Sptz87 không hoàn toàn đúng, Bạn có thể sử dụng lệnh linen và nếu bạn thêm https://github.com/shundhammer/qdirstat/tree/master/scripts này, bạn cũng có thể sử dụng cron để làm điều đó thường xuyên

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.