วิธีการแก้ไขข้อผิดพลาด“ ไม่มีพื้นที่เหลือบนอุปกรณ์” ต่อเนื่องระหว่าง mv เมื่ออุปกรณ์มีพื้นที่เหลือเฟือ

• Ubuntu 14.04 บนเดสก์ท็อป
• ไดรฟ์ต้นฉบับ: / dev / sda1:
  ไดรฟ์โวลุ่ม เดียวขนาด 5TB ext4
• ปริมาณเป้าหมาย: / dev / mapper / archive-lvarchive: raid6 (mdadm) ปริมาณ 18TB พร้อม
  พาร์ทิชันlvm และ ext4

มีไฟล์ประมาณ 15 ล้านไฟล์ที่จะย้ายและบางไฟล์อาจซ้ำกัน (ฉันไม่ต้องการเขียนทับไฟล์ซ้ำ)

คำสั่งที่ใช้ (จากไดเรกทอรีต้นทาง) คือ:

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

สิ่งนี้เกิดขึ้นสองสามวันตามที่คาดไว้ แต่ฉันได้รับข้อผิดพลาดในการเพิ่มความถี่ เมื่อเริ่มต้นเป้าหมายไดรฟ์เต็มประมาณ 70% ตอนนี้จะอยู่ที่ 90% เคยเป็นประมาณ 1/200 ของการเคลื่อนไหวจะระบุและข้อผิดพลาดตอนนี้มันเกี่ยวกับ 1/5 ไม่มีไฟล์ใดที่มีขนาดเกิน 100Mb ส่วนใหญ่จะอยู่ที่ประมาณ 100k

ข้อมูลบางส่วน:

$ 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

นี่คือผลลัพธ์ของฉัน:

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

ฉันพบข้อผิดพลาดนี้มากมายโพสต์ แต่การพยากรณ์โรคไม่พอดี ปัญหาเช่น "ไดรฟ์ของคุณเต็มจริง" หรือ "คุณหมด inodes" หรือ "ไดรฟ์ข้อมูล / บูตเต็ม" ส่วนใหญ่พวกเขาจัดการกับซอฟต์แวร์ของบุคคลที่สามที่ก่อให้เกิดปัญหาเนื่องจากวิธีการจัดการไฟล์และพวกเขาทั้งหมดคงที่ซึ่งหมายความว่าทุกการย้ายล้มเหลว

ขอบคุณ

แก้ไข: นี่คือตัวอย่างล้มเหลวและไฟล์ที่ประสบความสำเร็จ:

FAILED (ยังอยู่ในไดรฟ์ต้นฉบับ)

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

สำเร็จ (ตามปริมาณเป้าหมาย)

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

นอกจากนี้ในขณะที่ไฟล์บางไฟล์ล้มเหลวไฟล์ที่ล้มเหลวจะล้มเหลวเสมอ ถ้าฉันลองอีกครั้งมันจะสอดคล้องกัน

แก้ไข: คำสั่งเพิ่มเติมบางอย่างต่อคำขอโดย @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

ข้อบกพร่องในการใช้งานคุณสมบัติ ext4 dir_indexที่คุณใช้ในระบบไฟล์ปลายทางของคุณ

การแก้ไข: สร้าง filesytem ใหม่โดยไม่ใช้ dir_index หรือปิดการใช้งานคุณสมบัติโดยใช้ tune2fs (จำเป็นต้องมีข้อควรระวังโปรดดูที่ลิงค์ที่เกี่ยวข้องNovell SuSE 10/11: ปิดการใช้งานการทำดัชนี H-Tree บนระบบไฟล์ ext3ซึ่งแม้ว่าเกี่ยวข้องกับext3อาจต้องใช้ความระมัดระวังที่คล้ายกัน

(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: ลึกลับ“ ไม่มีพื้นที่เหลือบนอุปกรณ์” - ผู้บุกรุก

ext4 มีคุณสมบัติที่เรียกว่า dir_index เปิดใช้งานตามค่าเริ่มต้นซึ่งค่อนข้างไวต่อการแฮชชน

......

ext4 มีความเป็นไปได้ที่จะแฮชชื่อไฟล์ของเนื้อหา สิ่งนี้ช่วยเพิ่มประสิทธิภาพ แต่มีปัญหา“ เล็ก”: ext4 จะไม่เพิ่ม hashtable เมื่อเริ่มเติมเต็ม แต่จะคืนค่า -ENOSPC หรือ“ ไม่มีพื้นที่เหลือบนอุปกรณ์”

คำแนะนำสำหรับตัวเลือกที่ดีกว่า ext4 สำหรับการจัดเก็บไฟล์จำนวนมาก:

หากคุณใช้ระบบไฟล์เป็นที่เก็บอ็อบเจ็กต์คุณอาจต้องการดูการใช้ระบบไฟล์ที่มีความเชี่ยวชาญซึ่งอาจเป็นอันตรายต่อลักษณะอื่น ๆ การค้นหาโดย Google อย่างรวดเร็วพบCephซึ่งดูเหมือนว่าเป็นโอเพนซอร์สและสามารถติดตั้งเป็นระบบไฟล์ POSIX แต่ยังสามารถเข้าถึงได้ด้วย API อื่น ๆ ฉันไม่รู้ว่ามันคุ้มค่าที่จะใช้กับโฮสต์เดียวหรือไม่โดยไม่ใช้ประโยชน์จากการทำซ้ำ

ระบบการจัดเก็บวัตถุก็คือOpenStack ของสวิฟท์ เอกสารการออกแบบของมันบอกว่ามันเก็บแต่ละวัตถุเป็นไฟล์แยกต่างหากกับข้อมูลเมตาใน xattrs นี่คือบทความเกี่ยวกับมัน ของพวกเขาคู่มือการใช้งานบอกว่าพวกเขาพบ XFS ให้ประสิทธิภาพที่ดีที่สุดสำหรับการจัดเก็บวัตถุ ดังนั้นแม้ว่าปริมาณงานไม่ใช่สิ่งที่ดีที่สุดของ XFS แต่ก็เห็นได้ชัดว่าดีกว่าคู่แข่งเมื่อ RackSpace ทดสอบสิ่งต่าง ๆ อาจเป็นไปได้ว่า Swift โปรดปราน XFS เนื่องจาก XFS ได้รับการสนับสนุนที่ดี / รวดเร็วสำหรับแอตทริบิวต์เพิ่มเติม อาจเป็นไปได้ว่า ext3 / ext4 น่าจะตกลงบนดิสก์เดี่ยวเป็นแบ็กเอนด์ที่เก็บวัตถุหากไม่ต้องการข้อมูลเมตาเพิ่มเติม (หรือเก็บไว้ในไฟล์ไบนารี)

สวิฟท์ไม่ทำแบบจำลอง / ดุลการโหลดสำหรับคุณและแสดงให้เห็นว่าคุณให้มันทำแฟ้มบนดิสก์ดิบไม่ RAID มันชี้ให้เห็นว่าปริมาณงานนั้นแย่ที่สุดสำหรับ RAID5 (ซึ่งสมเหตุสมผลถ้าเรากำลังพูดถึงเวิร์กโหลดที่มีการเขียนไฟล์ขนาดเล็กโดยทั่วไป XFS มักจะไม่บรรจุพวกเขาแบบตัวต่อตัวดังนั้นคุณจึงไม่ รับการเขียนแบบเต็มแถบและ RAID5 ต้องอ่านเพื่อปรับปรุงแถบสไทรพ์เอกสาร Swift ยังพูดคุยเกี่ยวกับการใช้ 100 พาร์ติชันต่อไดรฟ์ฉันคิดว่านั่นเป็นคำที่รวดเร็วและไม่ได้พูดถึงการสร้างระบบไฟล์ XFS ที่แตกต่างกัน 100 รายการ ดิสก์ SATA

การใช้งาน XFS แยกต่างหากสำหรับดิสก์ทุกตัวนั้นแตกต่างกันมาก แทนที่จะเป็นหนึ่งในแผนที่ฟรี inode ขนาดมหึมาแต่ละดิสก์จะมี XFS แยกต่างหากพร้อมกับรายชื่ออิสระแยกต่างหาก นอกจากนี้ยังหลีกเลี่ยงการลงโทษ RAID5 สำหรับการเขียนขนาดเล็ก

หากคุณมีซอฟต์แวร์ของคุณที่สร้างขึ้นเพื่อใช้ระบบไฟล์โดยตรงเป็นที่เก็บวัตถุแทนที่จะทำบางอย่างเช่น Swift เพื่อจัดการกับการจำลอง / โหลดบาลานซ์ดังนั้นอย่างน้อยคุณสามารถหลีกเลี่ยงไฟล์ทั้งหมดของคุณในไดเรกทอรีเดียว (ฉันไม่เห็น Swift docs พูดว่าพวกเขาวางไฟล์ลงในหลาย ๆ ไดเรกทอรีได้อย่างไร แต่ฉันมั่นใจว่าพวกเขาทำ)

ด้วยระบบไฟล์เกือบทุกชนิดมันจะช่วยในการใช้โครงสร้างเช่น

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

อาจจะมีความยาวประมาณ 10k รายการดังนั้นการจดชื่อวัตถุของคุณไว้อย่างละ 4 ตัวและใช้มันเป็นไดเรกทอรีจึงเป็นทางออกที่ง่าย มันไม่จำเป็นต้องมีความสมดุลอย่างดี ไดเรกทอรี 100k แปลก ๆ อาจจะไม่ใช่ปัญหาที่สังเกตได้และจะไม่มีไดเรกทอรีว่างเปล่า

XFSไม่เหมาะสำหรับไฟล์ขนาดเล็กจำนวนมาก มันทำในสิ่งที่ทำได้ แต่มันเหมาะสำหรับการสตรีมไฟล์ที่มีขนาดใหญ่กว่า โดยรวมแล้วถือว่าดีมากสำหรับการใช้งานทั่วไป มันไม่ได้มีENOSPCการชนกันในการทำดัชนีไดเรกทอรี (AFAIK) และสามารถจัดการกับการมีหนึ่งไดเรกทอรีที่มีรายการนับล้าน (แต่ก็ยังดีกว่าที่จะใช้ต้นไม้อย่างน้อยหนึ่งระดับ)

Dave Chinner มีความคิดเห็นเกี่ยวกับประสิทธิภาพของ XFS ด้วยการจัดสรร inode จำนวนมากซึ่งนำไปสู่ความช้าtouchประสิทธิภาพที่การหาไอโนดอิสระเพื่อจัดสรรเริ่มใช้เวลา CPU มากขึ้นเนื่องจากบิตแมปไอโหนดอิสระได้รับการแยกส่วน โปรดทราบว่านี่ไม่ใช่ปัญหาของไดเรกทอรีขนาดใหญ่เปรียบเทียบกับหลายไดเรกทอรี แต่เป็นปัญหาของ inodes ที่ใช้จำนวนมากในระบบไฟล์ทั้งหมด การแบ่งไฟล์ของคุณออกเป็นหลาย ๆ ไดเรกทอรีช่วยในปัญหาบางอย่างเช่นไฟล์ที่ ext4 ติดอยู่ใน OP แต่ไม่ใช่ปัญหาเกี่ยวกับดิสก์ทั้งตัวในการติดตามพื้นที่ว่าง ระบบไฟล์ต่อดิสก์แยกต่างหากของ Swift ช่วยในเรื่องนี้เมื่อเทียบกับ XFS ขนาดยักษ์บน RAID5

ฉันไม่รู้ว่าbtrfsนี้ดีหรือไม่ แต่ฉันคิดว่าอาจเป็นเช่นนั้น ฉันคิดว่า Facebook ใช้นักพัฒนานำของตนด้วยเหตุผล : P มาตรฐานบางอย่างที่ฉันเห็นสิ่งที่ไม่ได้มาจากเคอร์เนล Linux แสดงว่า btrfs ทำงานได้ดี

ฉันรู้ว่าreiserfsได้รับการปรับปรุงสำหรับกรณีนี้ แต่มันก็แทบจะไม่ได้รับการบำรุงรักษาอีกต่อไป ฉันไม่สามารถแนะนำให้ไปกับ reiser4 มันอาจเป็นเรื่องที่น่าสนใจสำหรับการทดลอง แต่มันเป็นทางเลือกที่พิสูจน์ได้ในอนาคตอย่างน้อยที่สุด ฉันยังได้เห็นรายงานการลดลงของประสิทธิภาพใน reiserFS ที่มีอายุมากขึ้นและไม่มีเครื่องมือการดีแฟรกต์ที่ดี (google filesystem millions of small filesและดูคำตอบ stackexchange ที่มีอยู่บางส่วน)

ฉันอาจจะขาดอะไรบางอย่างดังนั้นคำแนะนำสุดท้าย: ถามเกี่ยวกับเรื่องนี้ใน serverfault! ถ้าฉันต้องเลือกอะไรตอนนี้ฉันจะบอกว่าลอง BTRFS แต่ให้แน่ใจว่าคุณมีข้อมูลสำรอง (โดยเฉพาะถ้าคุณใช้ดิสก์หลายตัวในตัวของ BTRFS แทนการรันที่ด้านบนของ RAID ข้อได้เปรียบด้านประสิทธิภาพอาจมีขนาดใหญ่เนื่องจากไฟล์ขนาดเล็กเป็นข่าวร้ายสำหรับ RAID5 เว้นแต่ว่าเป็นภาระงานที่อ่านได้เป็นส่วนใหญ่)

สำหรับปัญหาด้านล่างนี้เป็นสิ่งที่ฉันแก้ไข (คุณอาจต้องเข้าถึง sudo สำหรับขั้นตอนด้านล่าง):

1. พื้นที่ที่ใช้ของ Inodes คือ 100% ซึ่งสามารถเรียกดูได้โดยใช้คำสั่งด้านล่าง

   df -i /

Filesystem Inodes IUsed IFree IUse% ติดตั้งอยู่

/dev/xvda1            524288   524288  o     100% /

2. จำเป็นต้องเพิ่ม iNoted ให้ว่างดังนั้นต้องค้นหาไฟล์ที่มีจำนวนโหนด i ที่นี่โดยใช้คำสั่งด้านล่าง:

ลองค้นหาว่านี่เป็นปัญหา inodes กับ:

df -ih

ลองค้นหาโฟลเดอร์รูทที่มี inode ใหญ่นับ:

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

ลองค้นหาโฟลเดอร์เฉพาะ:

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

3. ตอนนี้เราได้ zeroed ลงในโฟลเดอร์ที่มีไฟล์จำนวนมากในนั้น เรียกใช้คำสั่งด้านล่างหนึ่งหลังจากนั้นอีกเพื่อหลีกเลี่ยงข้อผิดพลาดใด ๆ (ในกรณีของฉันโฟลเดอร์ที่แท้จริงคือ / 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 {} +