btrfs, không còn đĩa


2

Tôi có một vấn đề với không gian đĩa ở âm lượng btrfs. df cho thấy có rất nhiều không gian đĩa. Nhưng khi tôi đang cố sao chép hệ thống tệp kiểm tra 10GB thì không có dung lượng đĩa trên thiết bị này.

df -h | grep /mnt/ssd:

/dev/sda 448G 135G 313G 31% /mnt/ssd

Tương tự ở đây:

btrfs filesystem df /mnt/ssd:

Data, RAID1: total=446.12GiB, used=133.29GiB
System, RAID1: total=8.00MiB, used=80.00KiB
Metadata, RAID1: total=1.00GiB, used=609.05MiB
GlobalReserve, single: total=405.53MiB, used=0.00B

Tôi không biết cách đọc đầu ra của cái này:

sudo btrfs filesystem show:

Label: none  uuid: aba64e21-69d1-46c1-b3f2-dfda832b67fd
    Total devices 2 FS bytes used 133.88GiB
    devid    1 size 447.13GiB used 447.13GiB path /dev/sda
    devid    2 size 447.13GiB used 447.13GiB path /dev/sdb

Vậy có 133,88GiB hay 447,13GiB được sử dụng? Rất bối rối.

Câu trả lời:


3

Để hiểu những gì đang diễn ra ở đây, trước tiên bạn cần hiểu rằng BTRFS sử dụng bộ phân bổ hai giai đoạn. Giai đoạn đầu phân bổ các khối không gian lớn (thực sự được gọi là 'khối' trong hầu hết các tài liệu) được sử dụng cho chính xác một loại phân bổ, hoặc là dữ liệu (chỉ được sử dụng cho dữ liệu trong tệp), siêu dữ liệu (những thứ như tên tệp, thư mục cấu trúc, thời gian truy cập, quyền sở hữu, quyền, v.v.) hoặc hệ thống (chỉ được sử dụng để lưu trữ dữ liệu về phân bổ khối). Khi một đoạn đã được phân bổ, không gian trong đoạn đó chỉ có thể được giải phóng bằng cách di chuyển tất cả dữ liệu ra khỏi nó.

Vì vậy, điều này chính xác có nghĩa là gì trong hệ thống tập tin của bạn?

Vâng, đầu ra của bạn từ btrfs filesystem df hiển thị như sau:

Data, RAID1: total=446.12GiB, used=133.29GiB
System, RAID1: total=8.00MiB, used=80.00KiB
Metadata, RAID1: total=1.00GiB, used=609.05MiB
GlobalReserve, single: total=405.53MiB, used=0.00B

Các total các giá trị cho biết có bao nhiêu không gian đã được phân bổ cho loại khối đó, trong khi used giá trị cho thấy có bao nhiêu không gian được sử dụng trong các khối đó. Trong trường hợp của bạn, bạn có 446.32GB dung lượng được phân bổ cho các khối dữ liệu (gần như toàn bộ đĩa dựa trên thông thường dfbtrfs filesystem show đầu ra), nhưng chỉ có 133,29GB dung lượng đó thực sự được sử dụng. Do điều này và các triệu chứng được mô tả, BTRFS đang cố gắng phân bổ một khối siêu dữ liệu nhưng không có không gian để làm điều đó (vì tất cả không gian trống nằm trong các khối đã được phân bổ), vì vậy bạn chỉ gặp lỗi.

Để phục hồi từ điều này, bạn sẽ phải chạy một số dư. Một số dư hoàn toàn theo nghĩa đen sẽ gửi tất cả dữ liệu từ các khối được chọn (hoặc tất cả chúng nếu bạn không có tùy chọn nào) trở lại qua bộ cấp phát, có tác dụng ròng là giải phóng các khối trống hoặc chủ yếu là trống vì nó đóng gói lại thành một phần đầy đủ.

Tôi sẽ bắt đầu với:

btrfs balance start -dusage=0 /mnt/ssd

Điều đó sẽ loại bỏ tất cả các khối dữ liệu không có dữ liệu thực tế trong đó, có thể đủ để mọi thứ hoạt động trở lại, nhưng vẫn khiến bạn dễ gặp phải vấn đề tương tự trong tương lai.

Để giúp thu gọn mọi thứ hoàn toàn, hãy lặp lại lệnh trên với giá trị tăng dần cho -dusage Tùy chọn. Tôi thường tăng gấp 5 lần mỗi lần lên tới khoảng 50 (trên 50, bạn thường lãng phí thời gian). Bộ lọc sử dụng (được chỉ định ở trên chỉ để xử lý các khối dữ liệu) sẽ cho biết sự cân bằng để chọn các khối chỉ có đầy đủ phần trăm đó, do đó, bằng cách tăng dần từng chút một, bạn có thể dễ dàng thu gọn mọi thứ mà không gặp phải các vấn đề khác.

Bạn có thể giúp giải quyết các vấn đề như thế này trong tương lai bằng cách chạy một số thứ như sau thường xuyên (tôi thường chạy nó hàng ngày trên hệ thống của mình):

btrfs balance start -dusage=25 -dlimit=10 -musage=25 -mlimit=10 /mnt/ssd

Điều đó sẽ cân bằng 10 khối dữ liệu và siêu dữ liệu đầu tiên chưa đầy một phần tư, sẽ hoàn thành trong vài giây trong hầu hết các trường hợp.


Hơn bạn cho câu trả lời toàn diện này. Mọi thứ trở nên tốt hơn sau khi cân bằng với -dusage = 25. Bây giờ tôi có khoảng 50% dung lượng trống :). Bạn có thể cho tôi biết tại sao việc cân bằng với -dusage trên 50 là lãng phí thời gian?
Kristopher

@Kristopher Đó thực chất là một vấn đề hiệu quả. Càng nhiều dữ liệu trong một khối, càng mất nhiều thời gian để di chuyển dữ liệu sang một đoạn mới và lợi ích của nó sẽ càng thấp khi giải quyết loại vấn đề này. Bằng cách chỉ tập trung vào các phần chưa đầy một nửa, bạn có một đảm bảo hợp lý rằng bạn sẽ giải phóng rất nhiều không gian, trong khi việc cân bằng các phần lớn hơn một nửa chỉ có thể giải phóng một phần duy nhất (nếu nó giải phóng được tất cả ).
Austin Hemmelgarn

1

Tôi chưa bao giờ gặp sự cố loại này với hệ thống tệp Btrfs trên ổ cứng, nhưng tôi cũng bị như vậy trên ổ SSD của mình. SSD không biết khối nào thực sự miễn phí, bạn cần phải cắt nó.

Nhưng khi sự cố xảy ra fstrim -v /mnt/ssd cho thấy hầu như không có không gian được cắt! Giải pháp của tôi:

btrfs balance start /mnt/ssd
  #  you can monitor its progress by 'btrfs balance status /mnt/ssd'
fstrim -v /mnt/ssd

Lệnh thứ hai sẽ cắt rất nhiều không gian lần này. Sau đó, không gian trống của tôi thực sự có sẵn cho tôi.

Tuy nhiên, xin lưu ý: Tôi đang sử dụng Btrfs trên một ổ SSD, có Không RAID trong trường hợp của tôi và tôi không biết liệu nó có khác biệt gì không (tôi đang tính vào phản hồi của bạn).


Về phần khó hiểu: Btrfs như một hệ thống tập tin có thể phóng to hoặc thu nhỏ bên trong một thiết bị (hoặc thiết bị) được gán cho nó. Hiện tại hệ thống tập tin của bạn đang cồng kềnh. Nó sử dụng toàn bộ 447.13GiB trên mọi thiết bị. Tôi nghĩ rằng toàn bộ không gian này là "đang sử dụng" miễn là fstrim là có liên quan. Bên trong hệ thống tập tin 133.29GiB được sử dụng bởi dữ liệu thực tế mặc dù. Cân bằng hệ thống tập tin nên thu nhỏ nó và chỉ sau đó fstrim có thể làm công việc của nó.

Hệ thống tập tin sẽ phình to trở lại theo thời gian. Đó là lý do tại sao tôi học cách thực hiện bảo trì trên định kỳ, đặc biệt là trước đây apt-get upgrade.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.