Không có dung lượng trên thiết bị khi xóa tệp trong OpenSolaris

Trong khi cố gắng gắn kết một chia sẻ NFS (được xuất từ máy chủ OpenIndiana ) trên hộp máy khách, máy chủ OI đã gặp sự cố. Tôi nhận được màn hình đen của cái chết, trông giống như một bãi rác, sau đó hệ thống được phục hồi. Nó không bao giờ xuất hiện trở lại và tôi nhận được thông báo lỗi sau khi tôi dừng khởi động:

svc.startd[9] Could not log for svc:/network/dns/mulitcast:default: write(30) failed with No space left on device?

Tôi không có bất cứ thứ gì khác trên ổ đĩa khởi động ngoài HĐH nên ... Tôi không chắc cái gì có thể lấp đầy ổ đĩa? Có lẽ một tệp nhật ký của một số loại? Tôi dường như không thể xóa bất cứ điều gì bất kể. Nó không cho tôi lỗi không gian khi tôi thử xóa bất cứ thứ gì:

$ rm filename
cannot remove 'filename' : No space left on device 

Tôi có thể đăng nhập vào "Chế độ bảo trì" nhưng không phải là dấu nhắc người dùng chuẩn.

Đầu ra của dflà:

rpool/ROOT/openindiana-baseline    4133493    4133493          0    100%   /
swap                              83097900      11028  830386872      1%   /etc/svc/volatile
/usr/lib/libc/libc_hwcap1.so.1     4133493    4133493          0    100%   /lib/libc.so.1

Đầu ra của mountlà:

/ on rpool/ROOT/openindiana-baseline read/write/setuid/devices/dev:2d9002 on Wed Dec 31 16:00:00 1969
/devices on /devices read/write/setuid/devices/dev:8b40000 on Fri Jul 8 14:56:54 2011
/dev on /dev read/write/setuid/devices/dev:8b80000 on Fri Jul 8 14:56:54 2011
/system/contract on ctfs read/write/setuid/devices/dev:8c40001 on Fri Jul 8 14:56:54 2011
/proc on proc read/write/setuid/devices/dev:8bc0000 on Fri Jul 8 14:56:54 2011
/etc/mnttab on mnttab read/write/setuid/devices/dev:8c80001 on Fri Jul 8 14:56:54 2011
/etc/svc/volatile on swap read/write/setuid/devices/xattr/dev:8cc0001 on Fri Ju8 14:56:54 2011
/system/object on objfs read/write/setuid/devices/dev:8d00001 on Fri Jul 8 14:6:54 2011
/etc/dfs/sharetab on sharefs read/write/setuid/devices/dev:8d40001 on Fri Jul 14:56:54 2011
/lib/libc.s0.1 on /usr/lib/libc/libc_hucap1.s0.1 read/write/setuid/devices/dev:d90002 on Fri Jul 8 14:57:06 2011 

Đầu ra của 'danh sách zfs -t all' là:

rpool                                                       36.4G   0       47.5K   /rpool
rpool/ROOT                                                  4.23G   0         31K   legacy
rpool/ROOT/openindiana                                      57.5M   0       3.99G   /
rpool/ROOT/openindiana-baseline                             61K     0       3.94G   /
rpoo1/ROOT/openindiana-system-edge                          4.17G   0       3.98G   /
rpool/ROOT/openindiana-system-edge@install                  19.9M   -       3 38G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:45:08      73.1M   -       3.57G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:48:53      75.9M   -       3 82G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:14:04      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:15:14      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:28:14      61K     -       3.94G   -
rpool/ROOT/openindiana-system-stable                        61K     0       3.94G   /
rpoo1/ROOT/pre_first_update_07.06                           108K    0       3 82G   /
rpool/ROOT/pre_second_update_07.06                          90K     0       3.57G   /
rpool/dump                                                  9.07G   0       9.07G   -
rpool/export                                                3.85G   0       32K     /export
rpool/export/home                                           3.85G   0       32K     /export/home
rpool/export/home/admin                                     3.85G   0       3.85G   /export/home/admin
rpool/swap                                                  19.3G   19.1G   126M    -

Ok, đó là một người kỳ quặc không đủ dung lượng để xóa tệp!

Điều này hóa ra là một vấn đề tương đối phổ biến với ZFS, mặc dù nó có khả năng phát sinh trên bất kỳ hệ thống tệp nào có ảnh chụp nhanh .

Giải thích là tệp bạn đang cố xóa vẫn tồn tại trên ảnh chụp nhanh. Vì vậy, khi bạn xóa nó, nội dung sẽ tồn tại (chỉ trong ảnh chụp nhanh); và hệ thống phải ghi thêm thông tin rằng ảnh chụp nhanh có tệp nhưng trạng thái hiện tại thì không. Không còn chỗ trống cho chút thông tin đó.

Cách khắc phục ngắn hạn là tìm một tệp được tạo sau ảnh chụp nhanh nhất và xóa nó. Một khả năng khác là tìm một tệp được thêm vào sau ảnh chụp nhanh nhất và cắt nó theo kích cỡ của nó tại thời điểm ảnh chụp nhanh nhất. Nếu đĩa của bạn đã đầy vì có gì đó đang spam nhật ký của bạn, hãy thử cắt bớt các tệp nhật ký lớn nhất.

Một sửa chữa thường được áp dụng là để loại bỏ một số ảnh chụp nhanh. Bạn có thể liệt kê các ảnh chụp nhanh với zfs list -t snapshot. Dường như không có cách nào dễ dàng để dự đoán sẽ lấy lại được bao nhiêu dung lượng nếu bạn phá hủy một ảnh chụp nhanh cụ thể, bởi vì dữ liệu mà nó lưu trữ có thể cần đến bởi các ảnh chụp nhanh khác và vì vậy sẽ tồn tại nếu bạn phá hủy ảnh chụp nhanh đó. Vì vậy, hãy sao lưu dữ liệu của bạn vào một đĩa khác nếu cần, xác định một hoặc nhiều ảnh chụp nhanh mà bạn không còn cần nữa và chạy zfs destroy name/of/snap@shot.

Có một cuộc thảo luận mở rộng về vấn đề này trong chủ đề diễn đàn OpenSolaris này .

Đó là một vấn đề nổi tiếng với các hệ thống tệp sao chép khi ghi: Để xóa một tệp, trước tiên, hệ thống tệp cần phân bổ một khối và sửa trạng thái mới trước khi có thể giải phóng sự giàu có của không gian trong tệp vừa bị xóa.

(Đây không phải là vấn đề của hệ thống tập tin với ảnh chụp nhanh, vì có nhiều cách khác để thực hiện những điều này hơn là chỉ sao chép khi ghi)

Cách ra khỏi vắt:

• phát hành ảnh chụp nhanh (trong trường hợp có một ...)
• phát triển nhóm (trong trường hợp còn dư lại bạn có thể gán cho nó)
• phá hủy một hệ thống tập tin khác trong nhóm, sau đó phát triển hệ thống tập tin chặt chẽ
• cắt bớt tệp, sau đó loại bỏ nó (mặc dù một khi tôi đã quá chặt để có thể làm được điều đó, hãy xem chủ đề tại ZFS Thảo luận )
• hủy liên kết tập tin (giống như trên)

Tôi đã gặp phải cái bẫy tương tự vài năm trước và không có bất kỳ ảnh chụp nhanh nào tôi có thể phát hành để giải phóng tôi. Xem chủ đề tại ZFS Thảo luận về vấn đề này đã được thảo luận sâu.

4.Z3G (cột rpool / root USED) là không rõ ràng.

Trong mọi trường hợp, rpool / export / home / admin quá lớn (3,85 GB) có thể là nguyên nhân gốc rễ. Có một cái nhìn vào nội dung của nó và loại bỏ các tập tin không cần thiết ở đó. Vì hệ thống tệp quản trị không có ảnh chụp nhanh, điều này sẽ ngay lập tức giải phóng một số không gian trong nhóm.

Tôi đã có điều đó và dành một thời gian cố gắng để tìm ra những gì cần thiết. Giải pháp của tôi là loại bỏ không gian của các tập tin trước khi cố gắng xóa chúng.

Chúng tôi có một số quy trình xử lý sai đôi khi phát điên và lấp đầy đĩa bằng các tệp lõi (kết thúc bằng một số) vì vậy tôi đã tạo ra một tập lệnh có chứa một cái gì đó như thế này để giữ một bản sao.

for file in core*[0-9]
do
    coreFile=${file%.[0-9]*}

    mv $file $coreFile
    if [[ $? == 0 ]]
    then
        chmod 644 $coreFile
    else
        truncate -s 0 $file # we can't just delete if disk is full so zero out first
        rm $file
    fi
done

Khi tôi chạy tập lệnh của mình, nó tạo ra một lỗi:

mv: cannot rename core.200000 to core: No space left on device

và đã được chức năng xóa các tập tin.

Để kiểm tra điều này, tôi đã điền vào đĩa:

for ((ii=0; ii<100000; ii++))
do
    mkfile 1m core.$ii
done