มีเหตุผลอื่นอีกหรือไม่สำหรับ "ไม่มีพื้นที่เหลือบนอุปกรณ์"?

ฉันใช้ Dirvish บนระบบเซิร์ฟเวอร์ Ubuntu สำหรับการสำรอง hd ไปยังไดรฟ์ usb 3.0 ภายนอก เมื่อไม่กี่วันที่ผ่านมาทุกอย่างทำงานได้ดี แต่ตอนนี้การสำรองข้อมูลทั้งหมดล้มเหลวด้วย "ไม่มีพื้นที่เหลือบนอุปกรณ์ (28)" และ "ระบบไฟล์เต็ม" น่าเสียดายที่มันไม่ง่ายขนาดนั้น: มีอุปกรณ์ฟรี> 500 GB

รายละเอียด:

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]

บันทึกมีลักษณะค่อนข้างปกติจนกระทั่งฮิต:

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

แต่ดังที่ได้กล่าวข้างต้นมีพื้นที่บนอุปกรณ์มากมาย:

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

และยังมีไอโหนดเหลืออยู่จำนวนมาก:

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

อุปกรณ์ถูกเมานท์เป็น rw:

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

กระบวนการกำลังทำงานในฐานะรูท

ฉันกำลังจะบอกว่าฉันไม่ได้เปลี่ยนอะไรเลย แต่นั่นไม่จริงเลย: ฉันเปิด acl สำหรับไดรฟ์ที่ฉันสำรองไว้:

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

นั่นอาจเป็นปัญหาหรือไม่ ถ้าใช่เป็นอย่างไร รูทยังคงสามารถเข้าถึงไฟล์ได้อย่างสมบูรณ์

แก้ไข:

ฉันเพิ่งตรวจสอบไดเรกทอรีชั่วคราว:

• / tmp มีเฉพาะโฟลเดอร์. webmin ที่ว่างเปล่า
• / var / tmp ว่างเปล่า

ระบบไฟล์ที่มีไดเร็กทอรีเหล่านี้มีพื้นที่ว่างและ inodes มากมาย:

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:

ไดเรกทอรีมีขนาดค่อนข้างใหญ่ แต่ไม่เกิน> 2 GB ที่ที่การสำรองข้อมูลล้มเหลวไม่ได้เป็นหนึ่งในที่ใหญ่ที่สุด แต่ก็มีไฟล์ 7530

edit3:

ข้อมูลหนึ่งที่ฉันไม่ได้พิจารณาว่าเกี่ยวข้องเมื่อโพสต์คำถามนี้:

วันก่อนการสำรองข้อมูลเริ่มล้มเหลวฉันได้เปิดใช้งาน acls บนระบบไฟล์ที่ถูกสำรอง ฉันสมมติว่าตอนนี้สิ่งนี้เรียก Dirvish (หรือ rsync) เพื่อคิดว่าไฟล์ทั้งหมดมีการเปลี่ยนแปลงดังนั้นรายการของไฟล์ที่จะคัดลอกแทนที่จะเชื่อมโยงอย่างหนักนั้นมีขนาดใหญ่มาก นี่อาจหมายความว่าบัฟเฟอร์บางตัวมีขนาดเล็กเกินไป

วันนี้การสำรองข้อมูลเต็มไปยังดิสก์เปล่าทำงานได้อย่างไม่มีที่ติ ฉันจะลองสำรองข้อมูลเพิ่มเติม นี่จะแสดงว่าการเปิดใช้งาน acls เป็นสาเหตุของปัญหาหรือไม่

ความสงสัยของฉัน (ดู EDIT3) เห็นได้ชัดว่าถูกต้อง: การเพิ่มการสนับสนุน acl ลงในระบบไฟล์ทำให้ rsync / dirvish คิดว่าไฟล์ทั้งหมดมีการเปลี่ยนแปลง ดังนั้นแทนที่จะทำการสำรองข้อมูลเพิ่มเติมและเพียงสร้างฮาร์ดลิงก์ไปยังไฟล์ที่มีอยู่แล้วมันพยายามสร้างการสำรองข้อมูลเต็มรูปแบบซึ่งแน่นอนว่าล้มเหลวเนื่องจากฮาร์ดดิสก์ไม่มีพื้นที่เพียงพอสำหรับสิ่งนั้น

ดังนั้นข้อผิดพลาดถูกต้องจริง

หลังจากเริ่มต้นอีกครั้งด้วยดิสก์สำรองข้อมูลที่ว่างเปล่าการสำรองข้อมูลส่วนเพิ่มจะทำงานเหมือนเดิม

การดู inode เหลือ 2% ทำให้ฉันคิดถึงรากสำรองที่ระบบไฟล์ EXT กำหนด คุณอาจต้องการตรวจสอบสิ่งเหล่านี้:

1. " พื้นที่สงวนสำหรับรูทบนระบบไฟล์ - เพราะอะไร "
2. " ขนาดที่เหมาะสมสำหรับ" บล็อกระบบไฟล์ที่สงวนไว้ "สำหรับดิสก์ที่ไม่ใช่ระบบปฏิบัติการ? "

ฉันจะลอง. tar.gz บางส่วนของการสำรองข้อมูลเก่าหวังว่ามันจะลดจำนวนของ inodes ที่ใช้งานอยู่

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

ปัญหานี้เกิดจากการชนกันของแฮชบนอุปกรณ์บล็อกที่จัดรูปแบบด้วยระบบไฟล์ ext4 ซึ่งการทำดัชนีไดเรกทอรีถูกเปิดใช้งานโดยเฉพาะอย่างยิ่งที่ไดเรกทอรีเดียวโฮสต์ไฟล์มากกว่า 100k ในนั้นและชื่อของไฟล์จะถูกสร้างขึ้นจากอัลกอริทึมเดียวกัน .)

วิธีแก้ไขคือลองด้วยอัลกอริทึมการทำดัชนีไดเรกทอรีอื่น:

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

หรือปิดใช้งานการทำดัชนีไดเรกทอรีโดยสมบูรณ์สำหรับอุปกรณ์บล็อกนั้น (อาจทำให้ประสิทธิภาพลดลง)

tune2fs -O ^dir_index /dev/blockdev_name

อีกวิธีคือดูว่ามีอะไรอยู่ในไดเรกทอรีที่บรรจุไฟล์ดังกล่าวและแก้ไขซอฟต์แวร์

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

รายละเอียดของปัญหานี้นำเสนอโดย Axel Wagner ที่นี่

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

ไชโย

มีการ จำกัด ขนาด 2GB ในไดเรกทอรีตัวเอง - เช่นถ้าคุณมีไฟล์จำนวนมากที่ขนาดไดเรกทอรีคือ> 2GB (ไม่ใช่ขนาดของไฟล์ในไดเรกทอรี) คุณจะมีปัญหา ต้องบอกว่ามีเพียง 2.8M inodes ที่ใช้นั่นไม่น่าเป็นปัญหา มักเกิดขึ้นประมาณ 15M inodes

ดังนั้นอาจไม่ช่วยได้มากนัก - แต่ลอง ext4 บนอุปกรณ์สำรองของคุณ?

เพิ่มขีด จำกัด Inotify ผู้เฝ้าดูใน sysctl:

fs.inotify.max_user_watches = 100000 

และรีบูทหรือทำsysctl -wเวอร์ชั่นนั้นด้วย

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

ฉันขอแนะนำให้คุณตรวจสอบสิ่งอื่นสองสามอย่าง:

1. ดูว่าผู้เล่นชั่วคราวของคุณยังไม่เต็ม บางครั้งมันใช้สำหรับการจัดเก็บระดับกลางและได้รับเต็มได้อย่างง่ายดาย
2. ตรวจสอบว่ามีกระบวนการที่ยังคงมี descriptor อยู่กับไฟล์ที่ถูกลบหรือไม่ โอกาสมีโอกาสน้อยลงเนื่องจาก df รายงานขนาดที่เหมาะสม แต่ก็ยังไม่เจ็บ

ฉันเพิ่งพบหัวข้อนี้ในขณะที่ค้นหาวิธีแก้ไขปัญหาของฉัน

อย่างน้อยก็มีเหตุผลอื่นสำหรับ ENOSPC และฉันก็ชอบด้วย rsync เช่นกันในขณะที่คัดลอกจากระบบไฟล์ ZFS ไปยัง EXT4 หนึ่ง:

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

ในกรณีนี้:

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

man 7 xattr อธิบายว่า:

   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).

ในกรณีของฉันหมายความว่าฉันต้องฟอร์แมตระบบไฟล์ใหม่ทั้งหมด :-(