Có bất kỳ lý do nào khác để không còn chỗ trống trên thiết bị không?

Tôi đang sử dụng Dirvish trên hệ thống máy chủ Ubuntu để sao lưu hd sang ổ USB 3.0 bên ngoài. Cho đến vài ngày trước, mọi thứ đều hoạt động tốt, nhưng bây giờ mọi bản sao lưu đều thất bại với "không còn chỗ trống trên thiết bị (28)" và "hệ thống tệp đầy đủ". Thật không may, nó không đơn giản: Có> 500 GB miễn phí trên thiết bị.

Chi tiết:

rsync_error:

rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename1>.eDJiD9": No space left on device (28)
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename2>.RHuUAJ": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename3>.9tVK8Z": No space left on device (28)
rsync: write "/mnt/backupsys/shd/gesichert1/20130223_213242/tree/<SomeFilename4>.t3ARSV": No space left on device (28)
[... some more files ...]
rsync: connection unexpectedly closed (2712185 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

nhật ký trông khá nhiều như bình thường cho đến khi nó chạm:

<SomeFilename1>
<SomeFilename2>
<SomeFilename3>
<SomeFilename4>
<PartOfAFilename>filesystem full
write error, filesystem probably full
broken pipe
RESULTS: warnings = 0, errors = 1

Nhưng, như đã nói ở trên, có rất nhiều không gian trên thiết bị:

df -h
/dev/sdg1       2.7T  2.0T  623G  77% /mnt/backupsys/shd

và cũng có rất nhiều nút còn lại:

df -i
/dev/sdg1      183148544 2810146 180338398    2% /mnt/backupsys/shd

Thiết bị được gắn dưới dạng rw:

mount
/dev/sdg1 on /mnt/backupsys/shd type ext3 (rw)

Quá trình đang chạy như root.

Tôi đã định nói rằng tôi đã không thay đổi bất cứ điều gì nhưng điều đó không hoàn toàn đúng: Tôi đã bật acl cho ổ đĩa mà tôi đang sao lưu:

/dev/md0 on /mnt/md0 type ext4 (rw,acl)

Có thể đó là vấn đề? Nếu có, làm thế nào? root vẫn có quyền truy cập đầy đủ vào các tập tin.

BIÊN TẬP:

Tôi chỉ kiểm tra các thư mục tạm thời:

• / tmp chỉ chứa một thư mục .webmin trống
• / var / tmp trống

hệ thống tập tin nơi các thư mục này cư trú có nhiều không gian trống và các nút:

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       289G   55G  220G  20% /

df -i
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
/dev/sda1       19202048  167644  19034404    1% /

EDIT2:

Các thư mục khá lớn, nhưng không> 2 GB. Cái mà bản sao lưu thất bại thậm chí không phải là một trong những cái lớn nhất, nó chứa 7530 tệp.

EDIT3:

Một thông tin mà tôi không cho là có liên quan khi đăng câu hỏi này:

Một ngày trước khi các bản sao lưu bắt đầu thất bại, tôi đã kích hoạt các acls trên các hệ thống tệp được sao lưu. Bây giờ tôi giả sử rằng điều này đã kích hoạt Dirvish (hoặc rsync) để nghĩ rằng tất cả các tệp đã thay đổi nên danh sách các tệp sẽ được sao chép thay vì liên kết cứng là rất lớn. Điều này có thể có nghĩa là một số bộ đệm quá nhỏ.

Hôm nay một bản sao lưu đầy đủ vào một đĩa trống hoạt động hoàn hảo. Tôi sẽ thử một bản sao lưu gia tăng tiếp theo. Điều này sẽ cho thấy liệu kích hoạt acls có phải là nguyên nhân của vấn đề hay không.

Sự nghi ngờ của tôi (xem EDIT3) rõ ràng là đúng: Thêm hỗ trợ acl vào hệ thống tệp khiến rsync / dirvish nghĩ rằng tất cả các tệp đã thay đổi. Vì vậy, thay vì tạo một bản sao lưu gia tăng và chỉ tạo các liên kết cứng đến các tệp đã có, nó đã cố gắng tạo một bản sao lưu đầy đủ, tất nhiên là thất bại vì đĩa cứng không có đủ dung lượng cho điều đó.

Vì vậy, thông báo lỗi đã thực sự chính xác.

Sau khi bắt đầu lại với một đĩa sao lưu trống, các bản sao lưu gia tăng hoạt động như trước.

Nhìn vào 2% số nút còn lại khiến tôi suy nghĩ về dự trữ gốc mà hệ thống tập tin EXT áp đặt. Bạn có thể muốn kiểm tra những điều này:

1. " Dành không gian cho root trên hệ thống tập tin - tại sao? "
2. " Kích thước hợp lý cho các hệ thống tập tin của các khối dành riêng cho các đĩa không dành cho hệ điều hành? "

Tôi sẽ cố gắng .tar.gz một số bản sao lưu cũ hơn với hy vọng rằng nó sẽ làm giảm số lượng các nút được sử dụng.

Tôi thấy dummzeuch tìm ra giải pháp cho vấn đề của mình nhưng thực tế có một trường hợp nữa tôi tìm thấy nơi đĩa có thể có đủ inodes / dung lượng trống và vẫn hiển thị "không còn chỗ trống trên thiết bị" trong khi cố gắng chuyển một số thư mục nhất định.

Điều này được gây ra bởi các xung đột băm trên các thiết bị khối được định dạng bằng hệ thống tệp ext4 nơi chỉ mục thư mục được bật, đặc biệt khi thư mục đơn lưu trữ hơn 100k tệp trong đó và tên của các tệp được tạo từ cùng một thuật toán (tệp bộ đệm, tên tệp md5sum, v.v. .)

Giải pháp là thử với thuật toán lập chỉ mục thư mục khác:

tune2fs -E "hash_alg=tea" /dev/blockdev_name

hoặc để vô hiệu hóa hoàn toàn việc lập chỉ mục thư mục cho thiết bị khối đó (có thể ảnh hưởng đến hiệu suất)

tune2fs -O ^dir_index /dev/blockdev_name

Một giải pháp khác là xem những gì đang lấp đầy thư mục với các tệp như vậy và sửa phần mềm.

Giải pháp có thể là phân chia nội dung của thư mục với khối lượng tệp khổng lồ trong đó thành nhiều thư mục con riêng biệt.

Mô tả đầy đủ về vấn đề được trình bày bởi Axel Wagner tại đây

http://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html

Chúc mừng.

Có giới hạn kích thước 2GB trên chính thư mục - tức là nếu bạn có quá nhiều tệp có kích thước thư mục> 2GB (KHÔNG phải kích thước của các tệp trong thư mục), bạn sẽ gặp vấn đề. Phải nói rằng, chỉ với 2,8M inodes được sử dụng, đó không phải là một vấn đề. Thường xảy ra khoảng 15M inodes.

Vì vậy, điều này có thể không giúp ích nhiều - nhưng hãy thử ext4 trên thiết bị sao lưu của bạn?

Tăng giới hạn người theo dõi Inotify của bạn trong sysctl:

fs.inotify.max_user_watches = 100000 

Và khởi động lại, hoặc làm sysctl -wphiên bản đó cũng có.

Điều đó thường sẽ làm điều đó. Một cái gì đó có quá nhiều tệp được mở trong kernel và lỗi này hoàn toàn sai lệch. Dropbox là một ví dụ cổ điển về điều này.

Tôi sẽ đề nghị bạn kiểm tra một vài thứ khác:

1. Hãy xem nếu thư mục tạm thời của bạn không đầy đủ. Đôi khi nó được sử dụng để lưu trữ trung gian và nó được đầy đủ dễ dàng.
2. Kiểm tra nếu có một quá trình vẫn đang giữ một mô tả cho một tập tin bị xóa. Cơ hội ít có khả năng vì df báo cáo kích thước phù hợp nhưng vẫn không bị tổn thương.

Tôi vừa tìm thấy chủ đề này trong khi tìm kiếm một giải pháp cho vấn đề của tôi.

Thật vậy, có ít nhất về lý do khác cho ENOSPC. Và tôi cũng quảng cáo nó bằng rsync, trong khi sao chép từ hệ thống tệp ZFS sang EXT4:

rsync: rsync_xal_set: lsetxattr(""/my/file/path"","example.xattr.attribute") failed: No space left on device (28)

Trong trường hợp này:

   ENOSPC - There is insufficient space remaining to store the extended attribute.

man 7 xattr giải thích:

   In the current ext2, ext3, and ext4 filesystem implementations, the total bytes used by the names and values of all of a file's extended attributes
   must fit in a single filesystem block (1024, 2048 or 4096 bytes, depending on the block size specified when the filesystem was created).

Trong trường hợp của tôi, điều đó có nghĩa là tôi phải định dạng lại toàn bộ hệ thống tệp. :-(