Làm cách nào để khắc phục lỗi gián đoạn Không còn chỗ trống trên thiết bị Lỗi trong mv khi thiết bị có nhiều dung lượng?

• Ubuntu 14.04 trên máy tính để bàn
• Ổ đĩa nguồn: / dev / sda1: 5TB dung lượng
  ổ đĩa đơn ext4
• Khối lượng mục tiêu: / dev / mapper / archive-lvarchive: raid6 (mdadm) Âm lượng 18TB với
  phân vùng lvm và ext4

Có khoảng 15 triệu tệp để di chuyển và một số có thể trùng lặp (tôi không muốn ghi đè lên các bản sao).

Lệnh được sử dụng (từ thư mục nguồn) là:

ls -U |xargs -i -t mv -n {} /mnt/archive/targetDir/{}

Điều này đã diễn ra trong một vài ngày như mong đợi, nhưng tôi nhận được lỗi trong tần suất tăng dần. Khi nó bắt đầu ổ đĩa đích đã đầy khoảng 70%, bây giờ là khoảng 90%. Nó được sử dụng là khoảng 1/200 trong số các di chuyển sẽ nêu và lỗi, bây giờ là khoảng 1/5. Không có tệp nào trên 100Mb, hầu hết là khoảng 100k

Một số thông tin:

$ df -h
Filesystem                     Size  Used Avail Use% Mounted on
/dev/sdb3                      155G  5.5G  142G   4% /
none                           4.0K     0  4.0K   0% /sys/fs/cgroup
udev                           3.9G  4.0K  3.9G   1% /dev
tmpfs                          797M  2.9M  794M   1% /run
none                           5.0M  4.0K  5.0M   1% /run/lock
none                           3.9G     0  3.9G   0% /run/shm
none                           100M     0  100M   0% /run/user
/dev/sdb1                       19G   78M   18G   1% /boot
/dev/mapper/archive-lvarchive   18T   15T  1.8T  90% /mnt/archive
/dev/sda1                      4.6T  1.1T  3.3T  25% /mnt/tmp

$ df -i
Filesystem                       Inodes    IUsed     IFree IUse% Mounted on
/dev/sdb3                      10297344   222248  10075096    3% /
none                            1019711        4   1019707    1% /sys/fs/cgroup
udev                            1016768      500   1016268    1% /dev
tmpfs                           1019711     1022   1018689    1% /run
none                            1019711        5   1019706    1% /run/lock
none                            1019711        1   1019710    1% /run/shm
none                            1019711        2   1019709    1% /run/user
/dev/sdb1                       4940000      582   4939418    1% /boot
/dev/mapper/archive-lvarchive 289966080 44899541 245066539   16% /mnt/archive
/dev/sda1                     152621056  5391544 147229512    4% /mnt/tmp

Đây là đầu ra của tôi:

mv -n 747265521.pdf /mnt/archive/targetDir/747265521.pdf 
mv -n 61078318.pdf /mnt/archive/targetDir/61078318.pdf 
mv -n 709099107.pdf /mnt/archive/targetDir/709099107.pdf 
mv -n 75286077.pdf /mnt/archive/targetDir/75286077.pdf 
mv: cannot create regular file ‘/mnt/archive/targetDir/75286077.pdf’: No space left on device
mv -n 796522548.pdf /mnt/archive/targetDir/796522548.pdf 
mv: cannot create regular file ‘/mnt/archive/targetDir/796522548.pdf’: No space left on device
mv -n 685163563.pdf /mnt/archive/targetDir/685163563.pdf 
mv -n 701433025.pdf /mnt/archive/targetDir/701433025.pd

Tôi đã tìm thấy RẤT NHIỀU bài đăng về lỗi này, nhưng tiên lượng không phù hợp. Các vấn đề như "ổ đĩa của bạn đã thực sự đầy" hoặc "bạn đã hết inodes" hoặc thậm chí "khối lượng / boot của bạn đã đầy". Mặc dù vậy, hầu hết, họ xử lý phần mềm của bên thứ 3 gây ra sự cố do cách xử lý các tệp và tất cả đều không đổi, có nghĩa là MỌI di chuyển thất bại.

Cảm ơn.

EDIT: đây là một tệp thất bại và thành công:

FAILED (vẫn còn trên ổ đĩa nguồn)

ls -lhs 702637545.pdf
16K -rw-rw-r-- 1 myUser myUser 16K Jul 24 20:52 702637545.pdf

THÀNH CÔNG (Về khối lượng mục tiêu)

ls -lhs /mnt/archive/targetDir/704886680.pdf
104K -rw-rw-r-- 1 myUser myUser 103K Jul 25 01:22 /mnt/archive/targetDir/704886680.pdf

Ngoài ra, trong khi không phải tất cả các tệp đều thất bại, một tệp bị lỗi LUÔN LUÔN thất bại. Nếu tôi thử lại nhiều lần thì nó phù hợp.

EDIT: Một số lệnh bổ sung theo yêu cầu của @mjturner

$ ls -ld /mnt/archive/targetDir
drwxrwxr-x 2 myUser myUser 1064583168 Aug 10 05:07 /mnt/archive/targetDir

$ tune2fs -l /dev/mapper/archive-lvarchive
tune2fs 1.42.10 (18-May-2014)
Filesystem volume name:   <none>
Last mounted on:          /mnt/archive
Filesystem UUID:          af7e7b38-f12a-498b-b127-0ccd29459376
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              289966080
Block count:              4639456256
Reserved block count:     231972812
Free blocks:              1274786115
Free inodes:              256343444
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        512
Flex block group size:    16
Filesystem created:       Thu Jun 25 12:05:12 2015
Last mount time:          Mon Aug  3 18:49:29 2015
Last write time:          Mon Aug  3 18:49:29 2015
Mount count:              8
Maximum mount count:      -1
Last checked:             Thu Jun 25 12:05:12 2015
Check interval:           0 (<none>)
Lifetime writes:          24 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      3ea3edc4-7638-45cd-8db8-36ab3669e868
Journal backup:           inode blocks

$ tune2fs -l /dev/sda1
tune2fs 1.42.10 (18-May-2014)
Filesystem volume name:   <none>
Last mounted on:          /mnt/tmp
Filesystem UUID:          10df1bea-64fc-468e-8ea0-10f3a4cb9a79
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              152621056
Block count:              1220942336
Reserved block count:     61047116
Free blocks:              367343926
Free inodes:              135953194
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      732
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         4096
Inode blocks per group:   256
Flex block group size:    16
Filesystem created:       Thu Jul 23 13:54:13 2015
Last mount time:          Tue Aug  4 04:35:06 2015
Last write time:          Tue Aug  4 04:35:06 2015
Mount count:              3
Maximum mount count:      -1
Last checked:             Thu Jul 23 13:54:13 2015
Check interval:           0 (<none>)
Lifetime writes:          150 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      a266fec5-bc86-402b-9fa0-61e2ad9b5b50
Journal backup:           inode blocks

Lỗi trong việc triển khai tính năng ext4 dir_indexmà bạn đang sử dụng trên hệ thống tệp đích của mình.

Giải pháp: tạo lại fileytem mà không cần dir_index. Hoặc vô hiệu hóa tính năng bằng Tune2fs (cần thận trọng, xem liên kết liên quan Novell SuSE 10/11: Vô hiệu hóa lập chỉ mục H-Tree trên Hệ thống tập tin ext3 , mặc dù liên quan đến ext3 có thể cần thận trọng tương tự.

(get a really good backup made of the filesystem)
(unmount the filesystem)
tune2fs -O ^dir_index /dev/foo
e2fsck -fDvy /dev/foo
(mount the filesystem)

• ext4: Trò chơi bí ẩn không còn chỗ trống trên thiết bị

ext4 có một tính năng gọi là dir_index được bật theo mặc định, khá dễ bị va chạm băm.

......

ext4 có khả năng băm tên tệp của nội dung của nó. Điều này giúp nâng cao hiệu suất, nhưng có một vấn đề nhỏ trên mạng: ext4 không phát triển được hashtable của nó, khi nó bắt đầu lấp đầy. Thay vào đó, nó trả về -ENOSPC hoặc không còn chỗ trống trên thiết bị.

Gợi ý cho các lựa chọn tốt hơn ext4 để lưu trữ hàng loạt tệp nhỏ:

Nếu bạn đang sử dụng hệ thống tệp như một kho lưu trữ đối tượng, bạn có thể muốn xem xét việc sử dụng hệ thống tệp chuyên về điều đó, có thể gây bất lợi cho các đặc điểm khác. Một tìm kiếm nhanh của Google đã tìm thấy Ceph , dường như là nguồn mở và có thể được gắn kết dưới dạng hệ thống tệp POSIX, nhưng cũng được truy cập bằng các API khác. Tôi không biết có đáng để sử dụng trên một máy chủ không mà không tận dụng lợi thế của bản sao.

Một hệ thống lưu trữ đối tượng khác là Swift của OpenStack . Tài liệu thiết kế của nó nói rằng nó lưu trữ mỗi đối tượng dưới dạng một tệp riêng biệt, với siêu dữ liệu tính bằng xattrs . Đây là một bài viết về nó. Họ hướng dẫn triển khai nói rằng họ tìm thấy XFS cho hiệu suất tốt nhất cho việc lưu trữ đối tượng. Vì vậy, mặc dù khối lượng công việc không phải là thứ XFS giỏi nhất, nhưng rõ ràng nó tốt hơn so với các đối thủ khi RackSpace đang thử nghiệm mọi thứ. Có thể Swift ủng hộ XFS vì XFS có hỗ trợ tốt / nhanh cho các thuộc tính mở rộng. Có thể là ext3 / ext4 sẽ hoạt động tốt trên các đĩa đơn dưới dạng phụ trợ lưu trữ đối tượng nếu không cần siêu dữ liệu bổ sung (hoặc nếu nó được giữ trong tệp nhị phân).

Swift thực hiện sao chép / cân bằng tải cho bạn và đề nghị bạn cung cấp cho nó các hệ thống tệp được tạo trên các đĩa thô, không phải RAID . Nó chỉ ra rằng khối lượng công việc của nó về cơ bản là trường hợp xấu nhất đối với RAID5 (điều này hợp lý nếu chúng ta đang nói về một khối lượng công việc với việc ghi các tệp nhỏ. XFS thường không hoàn toàn đóng gói chúng, vì vậy bạn không nên nhận được ghi đầy đủ và RAID5 phải thực hiện một số lần đọc để cập nhật chuỗi chẵn lẻ. Các tài liệu Swift cũng nói về việc sử dụng 100 phân vùng trên mỗi ổ đĩa. Tôi cho rằng đó là thuật ngữ Swift và không nói về việc tạo 100 hệ thống tệp XFS khác nhau trên mỗi hệ thống Đĩa SATA.

Chạy một XFS riêng cho mỗi đĩa thực sự là một sự khác biệt rất lớn . Thay vì một bản đồ inode miễn phí khổng lồ , mỗi đĩa sẽ có một XFS riêng với các danh sách miễn phí riêng. Ngoài ra, nó còn tránh được hình phạt RAID5 khi ghi nhỏ.

Nếu bạn đã xây dựng phần mềm của mình để sử dụng trực tiếp hệ thống tệp như một kho lưu trữ đối tượng, thay vì đi qua một cái gì đó như Swift để xử lý sao chép / cân bằng tải, thì ít nhất bạn có thể tránh để tất cả các tệp của mình trong một thư mục. (Tôi không thấy các tài liệu Swift nói cách họ sắp xếp các tệp của họ vào nhiều thư mục, nhưng tôi chắc chắn họ làm như vậy.)

Với hầu hết mọi hệ thống tập tin bình thường, nó sẽ giúp sử dụng một cấu trúc như

1234/5678   # nested medium-size directories instead of
./12345678   # one giant directory

Có lẽ khoảng 10k mục là hợp lý, do đó, lấy 4 ký tự tên đối tượng của bạn và sử dụng chúng làm thư mục là một giải pháp dễ dàng. Nó không phải được cân bằng rất tốt. Thư mục 100k lẻ có lẽ sẽ không phải là vấn đề đáng chú ý và một số thư mục trống cũng không.

XFS không lý tưởng cho khối lượng lớn các tệp nhỏ. Nó làm những gì có thể, nhưng nó được tối ưu hóa hơn cho việc truyền phát các tệp lớn hơn. Mặc dù vậy, nó rất tốt cho sử dụng chung. Nó không có ENOSPCxung đột trong việc lập chỉ mục thư mục (AFAIK) và có thể xử lý việc có một thư mục với hàng triệu mục nhập. (Nhưng vẫn tốt hơn là sử dụng ít nhất một cây một cấp.)

Dave Chinner đã có một số ý kiến ​​về hiệu suất XFS với số lượng lớn các nút được phân bổ , dẫn đến touchhiệu suất chậm . Việc tìm kiếm một inode miễn phí để phân bổ bắt đầu tốn nhiều thời gian của CPU hơn, vì bitmap inode miễn phí bị phân mảnh. Lưu ý rằng đây không phải là vấn đề của một thư mục lớn so với nhiều thư mục, mà là vấn đề của nhiều nút được sử dụng trên toàn bộ hệ thống tệp. Việc chia các tệp của bạn thành nhiều thư mục sẽ giúp giải quyết một số vấn đề, như vấn đề mà ext4 mắc phải trong OP, nhưng không phải là vấn đề toàn bộ đĩa trong việc theo dõi không gian trống. Hệ thống tập tin riêng biệt trên mỗi đĩa của Swift giúp với điều này, so với trên XFS khổng lồ trên RAID5.

Tôi không biết nếu btrfs tốt về điều này, nhưng tôi nghĩ nó có thể. Tôi nghĩ rằng Facebook sử dụng nhà phát triển hàng đầu của mình vì một lý do. : P Một số điểm chuẩn tôi đã thấy, về những thứ như giải mã nguồn nhân Linux, cho thấy btrfs hoạt động tốt.

Tôi biết reiserfs đã được tối ưu hóa cho trường hợp này, nhưng nó hầu như không được duy trì nữa. Tôi thực sự không thể khuyên bạn nên đi với reiser4. Nó có thể thú vị để thử nghiệm, mặc dù. Nhưng đó là sự lựa chọn ít bằng chứng trong tương lai. Tôi cũng đã thấy các báo cáo về sự suy giảm hiệu suất trên reiserFS lâu đời và không có công cụ chống phân mảnh tốt. (google filesystem millions of small filesvà xem xét một số câu trả lời stackexchange hiện có.)

Có lẽ tôi đang thiếu một cái gì đó, vì vậy khuyến nghị cuối cùng: hãy hỏi về điều này trên serverfault! Nếu tôi phải chọn một cái gì đó ngay bây giờ, tôi muốn nói hãy thử BTRFS, nhưng hãy chắc chắn rằng bạn có bản sao lưu. (đặc biệt nếu bạn sử dụng dự phòng nhiều đĩa tích hợp của BTRFS, thay vì chạy nó trên RAID. Ưu điểm về hiệu năng có thể lớn, vì các tệp nhỏ là tin xấu cho RAID5, trừ khi đó là khối lượng công việc đọc chủ yếu.)

Đối với vấn đề này bên dưới là những gì tôi đã làm để khắc phục (bạn có thể cần quyền truy cập sudo cho các bước bên dưới):

1. Không gian sử dụng của Inodes là 100% có thể được truy xuất bằng lệnh bên dưới

   df -i /

Các nút hệ thống tập tin được sử dụng IFree IUse% được gắn vào

/dev/xvda1            524288   524288  o     100% /

2. Cần giải phóng iNote, do đó cần tìm các tệp có số nút i ở đây bằng lệnh dưới đây:

Hãy thử tìm xem đây có phải là sự cố inodes với:

df -ih

Cố gắng tìm các thư mục gốc có số lượng nút lớn:

for i in /*; do echo $i; find $i |wc -l; done

Cố gắng tìm các thư mục cụ thể:

for i in /src/*; do echo $i; find $i |wc -l; done

3. bây giờ chúng tôi đã chuyển xuống thư mục có số lượng lớn tệp trong đó. Lần lượt chạy các lệnh bên dưới để tránh bất kỳ lỗi nào (Trong trường hợp của tôi, thư mục thực tế là / var / spool / clientmqueue):

find /var/spool/clientmqueue/ -type f -mtime +1050 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +350 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +150 -exec rm -f {} +

find /var/spool/clientmqueue/ -type f -mtime +50 -exec rm -f {} +