Không còn chỗ trống trên thiết bị Lỗi mặc dù có nhiều dung lượng, trên btrfs


17

Hầu như ở mọi nơi tôi đều nhận được thất bại trong nhật ký phàn nàn về No space left on device

Nhật ký Gitlab:

==> /var/log/gitlab/nginx/current <==
2016-11-29_20:26:51.61394 2016/11/29 20:26:51 [emerg] 4871#0: open() "/var/opt/gitlab/nginx/nginx.pid" failed (28: No space left on device)

Nhật ký email của Dovecot:

Nov 29 20:28:32 aws-management dovecot: imap(email@www.sitename.com): Error: open(/home/vmail/emailuser/Maildir/dovecot-uidlist.lock) failed: No space left on device

Đầu ra của df -Th

Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/xvda1     ext4      7.8G  3.9G  3.8G  51% /
devtmpfs       devtmpfs  1.9G   28K  1.9G   1% /dev
tmpfs          tmpfs     1.9G   12K  1.9G   1% /dev/shm
/dev/xvdh      btrfs      20G   13G  7.9G  61% /mnt/durable
/dev/xvdh      btrfs      20G   13G  7.9G  61% /home
/dev/xvdh      btrfs      20G   13G  7.9G  61% /opt/gitlab
/dev/xvdh      btrfs      20G   13G  7.9G  61% /var/opt/gitlab
/dev/xvdh      btrfs      20G   13G  7.9G  61% /var/cache/salt

Hình như cũng có nhiều không gian inode. Đầu ra củadf -i

Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/xvda1     524288 105031 419257   21% /
devtmpfs       475308    439 474869    1% /dev
tmpfs          480258      4 480254    1% /dev/shm
/dev/xvdh           0      0      0     - /mnt/durable
/dev/xvdh           0      0      0     - /home
/dev/xvdh           0      0      0     - /opt/gitlab
/dev/xvdh           0      0      0     - /var/opt/gitlab
/dev/xvdh           0      0      0     - /var/cache/salt

Đầu ra của btrfs fi show

Label: none  uuid: 6546c241-e57e-4a3f-bf43-fa933a3b29f9
        Total devices 4 FS bytes used 11.86GiB
        devid    1 size 10.00GiB used 10.00GiB path /dev/xvdh
        devid    2 size 10.00GiB used 9.98GiB path /dev/xvdi
        devid    3 size 10.00GiB used 9.98GiB path /dev/xvdj
        devid    4 size 10.00GiB used 9.98GiB path /dev/xvdk

Đầu ra của btrfs fi df /mnt/durable

Data, RAID10: total=17.95GiB, used=10.12GiB
Data, single: total=8.00MiB, used=0.00
System, RAID10: total=16.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, RAID10: total=2.00GiB, used=1.74GiB
Metadata, single: total=8.00MiB, used=0.00
unknown, single: total=272.00MiB, used=8.39MiB

Điều gì có thể là nguyên nhân của việc này? Tôi đang sử dụng phiên bản cơ sở linux AMI ec2 kernal 4.4.5-15.26.amzn1.x86_64

Cập nhật

Chạy lệnh được đề xuất dưới đây btrfs fi balance start -dusage=5 /mnt/durableđã cho tôi một lỗi sau:

ERROR: error during balancing '/mnt/durable' - No space left on device There may be more info in syslog - try dmesg | tail

Sau khi xóa thủ công một loạt các tệp lớn hơn tổng cộng ~ 1GB, tôi đã khởi động lại máy và thử lại, đảm bảo rằng tôi đang sử dụng sudo và lệnh được thực thi. Sau đó tôi đã khởi động lại máy của mình một lần nữa để có biện pháp tốt và dường như nó đã giải quyết được vấn đề


Bạn có bất kỳ loại thiết lập hạn ngạch?
Zoredache

Các công cụ chung không thể hiểu đúng về BTRFS, bạn cần các công cụ cụ thể của BTRFS. Vui lòng thêm đầu ra của "btrfs fi show" và "btrfs fi df / mnt / bền"
Peter Green

@PeterGreen đã thêm đầu ra của btrfs ... có vẻ như bạn đã tìm ra thủ phạm.
Austin

Bạn cũng có thể thêm đầu ra của lệnh thứ hai mà tôi đề xuất.
Peter Green

2
Phiên bản kernel khá quan trọng ở đây, vì btrfs có khá nhiều vấn đề với không gian trống trong quá khứ và trong trường hợp đây là một ví dụ khác mà độc giả trong tương lai có thể hưởng lợi từ thông tin đó.
PlasmaHH

Câu trả lời:


19

Chào mừng đến với thế giới của BTRFS. Nó có một số tính năng trêu ngươi nhưng cũng có một số vấn đề gây phẫn nộ.

Trước hết, một số thông tin về thiết lập của bạn, có vẻ như bạn có bốn ổ đĩa trong một khối lượng "đột kích 10" BTRFS (vì vậy tất cả dữ liệu được lưu trữ hai lần trên các đĩa khác nhau). Khối lượng BTRFS này sau đó được khắc lên thành các subvolume trên các điểm gắn khác nhau. Các subvolume chia sẻ một nhóm không gian đĩa nhưng có số lượng inode riêng biệt và có thể được gắn ở những nơi khác nhau.

BTRFS phân bổ không gian trong "khối", một đoạn được phân bổ cho một lớp cụ thể của dữ liệu hoặc siêu dữ liệu. Điều có thể xảy ra (và có vẻ như đã xảy ra trong trường hợp của bạn) là tất cả không gian trống được phân bổ cho các khối dữ liệu không còn chỗ cho siêu dữ liệu

Dường như (vì lý do tôi không hiểu đầy đủ) rằng BTRF "hết" không gian siêu dữ liệu trước khi chỉ số về tỷ lệ không gian siêu dữ liệu được sử dụng đạt 100%.

Điều này dường như là những gì đã xảy ra trong trường hợp của bạn, có rất nhiều không gian dữ liệu miễn phí nhưng không có không gian trống chưa được phân bổ cho các khối và không đủ không gian trống trong các khối siêu dữ liệu hiện có.

Cách khắc phục là chạy "cân bằng lại". Điều này sẽ di chuyển dữ liệu xung quanh để một số khối có thể được đưa trở lại nhóm miễn phí "toàn cầu" nơi chúng có thể được phân bổ lại thành các khối siêu dữ liệu

btrfs fi balance start -dusage=5 /mnt/durable

Con số sau khi -dusagethiết lập mức độ cân bằng mạnh mẽ như thế nào, đó là khoảng cách gần các khối phải được viết lại. Nếu số dư cho biết nó viết lại 0 khối hãy thử lại với giá trị cao hơn -dusage.

Nếu cân bằng thất bại thì tôi sẽ thử khởi động lại và / hoặc giải phóng một số dung lượng bằng cách xóa các tệp.


9
tái cân bằng là sự phân mảnh mới.
Nathan Osman

1
Nhận ERROR: error during balancing '/mnt/durable' - No space left on devicengay cả sau khi xóa gần 1 GB khỏi ổ đĩa
Austin

Bạn đã thử khởi động lại (khởi động lại sau khi dọn dẹp làm việc cho tôi khi tôi gặp vấn đề tương tự).
Peter Green

@PeterGreen Đã thêm nội dung dmesg | tailtrong bài viết của tôi sau khi gặp lỗi mới sau khi khởi động lại.
Austin

4

Vì bạn đang chạy btrfs với thiết lập RAID, hãy thử chạy một hoạt động cân bằng.

btrfs balance start /var/opt/gitlab

Nếu điều này gây ra lỗi về việc không có đủ dung lượng, hãy thử lại với cú pháp sau:

btrfs balance start -musage=0 -dusage=0 -susage=0 /var/opt/gitlab 

Lặp lại thao tác này cho mỗi hệ thống tập tin btrfs nơi bạn đang thấy lỗi về không gian. Nếu vấn đề không gian của bạn là do siêu dữ liệu không được phân phối trên các đĩa được nhân đôi, điều này có thể giải phóng một số không gian cho bạn.


Tôi đã nhận được một lỗi về không gian. Khi thử cú pháp khác, nó hiển thị cho tôi những gì trông giống như một cảnh báo: Refusing to explicitly operate on system chunks. Pass --force if you really want to do that.Điều đó có ổn không?
Austin

Hãy thử nó mà không có -susage=0tùy chọn.
virtex

2

Trên hệ thống của tôi, tôi đã thêm công việc sau vào cron.monthly.

Cuộc clear_cachetái đấu là do một số vấn đề tham nhũng mà btrfs gặp phải với các bản đồ miễn phí. (Tôi nghĩ rằng cuối cùng họ đã tìm ra vấn đề, nhưng vấn đề rất khó chịu, tôi sẵn sàng trả tiền để xây dựng lại bản đồ mỗi tháng một lần.)

Tôi tăng cường các usagetùy chọn để giải phóng không gian dần dần cho số dư lớn hơn và lớn hơn.

#!/bin/sh

for mountpoint in `mount -t btrfs | awk '{print $3}' | sort -u`
do
    echo --------------------------
    echo Balancing $mountpoint :
    echo --------------------------
    echo remount with clear_cache...
    mount -oremount,clear_cache $mountpoint
    echo Before:
    /usr/sbin/btrfs fi show $mountpoint
    /usr/sbin/btrfs fi df $mountpoint
    for size in 0 1 5 10 20 30 40 50 60 70 80 90
    do
        time /usr/sbin/btrfs balance start -v -musage=$size $mountpoint 2>&1
        time /usr/sbin/btrfs balance start -v -dusage=$size $mountpoint 2>&1
    done
    echo After:
    /usr/sbin/btrfs fi show $mountpoint
    /usr/sbin/btrfs fi df $mountpoint
done

Nếu bạn đến điểm mà bạn không thể cân bằng lại vì bạn không đủ dung lượng, khuyến nghị là tạm thời thêm một thiết bị khối khác (hoặc thiết bị loopback trên một đĩa khác) vào âm lượng của bạn trong thời gian cân bằng lại, sau đó gỡ bỏ nó.


Cảm ơn rất nhiều @rrauenza! Kịch bản của bạn thực sự đã cứu ngày của tôi. Trong trường hợp của tôi, lệnh cân bằng đã thành công trong việc di chuyển các khối chỉ từ 60.
Michal Fapso

1

Đây không phải là một vấn đề với btrfs, vì đây là điều đã được thực hiện cho hệ thống này. Điều này trông giống như kết quả của sự cân bằng không hoàn chỉnh từ chính sách phân bổ 'một lần' sang chính sách phân bổ 'đột kích 10', bằng chứng là số lượng lớn các khối được phân bổ duy nhất. Nó có thể bắt đầu dưới dạng đơn và sau đó một chuyển đổi đã bị gián đoạn. Một nhóm với phân bổ không nhất quán như vậy chắc chắn có ... vấn đề phân bổ.

Hãy xem xét rằng bạn có 61% hồ bơi của bạn tiêu thụ. Chính sách phân bổ của bạn là RAID10, do đó sẽ dẫn đến mức tiêu thụ nhóm tối đa 50% trước khi đạt đầy đủ, vì mọi thứ đều được sao chép 2. Đây là lý do tại sao việc chuyển đổi của bạn từ đơn sang RAID 10 đã thất bại (và tiếp tục). Tôi chỉ có thể đoán, nhưng nó có lẽ đã được phân bổ vào giữa một sự cân bằng. Không còn chỗ trống trên thiết bị của bạn để cân bằng lại với RAID 10 với các đĩa bạn có. Lý do duy nhất bạn đạt tới 61% là do các đĩa của bạn được phân bổ không nhất quán, một số tuyến tính với phân bổ duy nhất và hầu hết trong RAID 10.

Bạn có thể cân bằng lại một chính sách phân bổ duy nhất nếu bạn muốn có được không gian mà không thay đổi nhiều thứ. Bạn cũng có thể thêm nhiều đĩa hoặc tăng kích thước của đĩa. HOẶC bạn có thể, như bạn đã làm trong trường hợp này, chỉ cần xóa một loạt các tệp để nhóm của bạn thực sự có thể cân bằng với RAID 10 (vì nó sẽ tiêu thụ ít hơn 50% tổng thể). Hãy đảm bảo bạn cân bằng lại sau khi xóa các tệp, hoặc bạn vẫn sẽ có chính sách phân bổ tưng bừng này.

Cụ thể, thực thi RAID 10 khi cân bằng lại sau khi xóa các tệp đó để đảm bảo bạn thoát khỏi các khối được phân bổ duy nhất đó, như vậy:

btrfs fi balance start -dconvert=raid10 -mconvert=raid10 /home

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.