NFS และ SMB รองรับไฟล์แบบกระจายหรือไม่?

ก่อนหน้านี้คำถามนี้ถูกถามในการล้นสแต็ก แต่คนที่ดีมีแนะนำให้ฉันลองชุมชนที่นี่แทน

ฉันกำลังค้นคว้าเกี่ยวกับไฟล์ที่กระจัดกระจายเกี่ยวกับระบบไฟล์ต่าง ๆ และกำลังพยายามค้นหาสิ่งที่เป็นรูปธรรมที่ระบุว่าไฟล์ sparse ได้รับการสนับสนุนโดย Network File Systems (NFS) หรือ Server Message Block (SMB)

ฉันเข้าใจว่า SMB มีการใช้กันอย่างแพร่หลายใน Windows และตามรายการนี้เซิร์ฟเวอร์ SMB สามารถรองรับไฟล์แบบกระจายได้แม้ว่าระบบไฟล์พื้นฐานจะไม่ อย่างไรก็ตามถ้าฉันพูดถูกระบบไฟล์ที่ไม่รองรับไฟล์ที่กระจัดกระจายก็จะเติมเต็ม 'หลุม' ด้วยศูนย์และนี่อาจทำให้เกิดปัญหาประสิทธิภาพ

ด้วยความนับถือ NFS ฉันไม่สามารถค้นหาอะไรเกี่ยวกับการใช้ NFS ที่สนับสนุนไฟล์แบบกระจาย

ดังนั้นคำถามของฉันคือ

รองรับไฟล์แบบกระจายใน NFS และ SMB หรือไม่

nfs server-message-block sparse-files

— winhung
แหล่งที่มา

คำตอบ:

NFS: มันมีการสนับสนุนบางส่วนสำหรับไฟล์กระจัดกระจาย โดยทั่วไปจะรองรับการสร้างไฟล์แบบเบาบาง แต่เมื่ออ่านไฟล์จะถูกขยายเพื่อรวมศูนย์ ซึ่งหมายความว่าในขณะที่คุณสามารถสร้างไฟล์ที่กระจัดกระจายผ่าน NFS เมื่ออ่านกลับไฟล์เดียวกันมากข้อมูลเครือข่ายระหว่างการขนส่งจะรวมเลขศูนย์ใด ๆ ที่พบในไฟล์ต้นฉบับ การทดสอบง่ายๆแสดงให้เห็นว่าพฤติกรรม:

cd /mnt/nfs
truncate test.img -s 1G
ls -lh test.img

-rw-R - r-- 1 root root 1.0G 26 ต.ค. 11:29 test.img

du -hs test.img

0 test.img

อย่างที่คุณเห็นไฟล์ test.img มีขนาดของดิสก์เป็น 0 ไบต์ อย่างไรก็ตามการอ่านกลับโดยใช้dd if=test.img of=/dev/null bs=1M iflag=directรายการ

1024 + 0 บันทึกใน
1024 + 0 บันทึกออก
1073741824 ไบต์ (1.1 GB), 10.2269 s, 105 MB / s

เป็นที่ชัดเจนว่าเมื่อถ่ายโอนไฟล์กระจัดกระจายจะถูกขยายเพื่อรวมศูนย์ทั้งหมด

NFSv4.2 จะขยายโดยรวมการจัดการพิเศษสำหรับการถ่ายโอนไฟล์เครือข่ายแบบกระจาย กล่าวอีกนัยหนึ่งด้วย NFSv4.2 ข้างต้นddจะเสร็จสมบูรณ์เกือบจะทันที

SMB: มันมีพฤติกรรมเช่นเดียวกับ NFSอย่างน้อยในสภาพแวดล้อมการทดสอบของฉันโดยใช้เซิร์ฟเวอร์ Samba v3.6.x พร้อม CIFS v1 และไคลเอนต์ Linux ที่ใช้ mount.cif บางทีภายใต้ Windows มันทำตัวต่างออกไป ...

— shodanshok
แหล่งที่มา

NFS สามารถรองรับไฟล์แบบกระจายได้หรือไม่หากระบบไฟล์พื้นฐานของเซิร์ฟเวอร์ NFS ไม่รองรับไฟล์แบบกระจาย

— Andrew Henle

@shodanshok: การทดสอบของคุณไม่ถูกต้อง รันคำสั่งเดียวกันบนระบบไฟล์ที่ไม่แฟ้มสนับสนุนเบาบางผลตอบแทนถัวเฉลี่ยผลเดียวกัน ddอ่านในบล็อกโดยบล็อกและระบบไฟล์ที่รองรับรองรับไฟล์หร็อมแหร็มหรือไม่รูจะกลายเป็นศูนย์โดยระบบปฏิบัติการ ลองใช้กับ ext4 แล้วคุณจะเห็นตัวเลขเดียวกัน

— abligh

@AndrewHenle ถ้า FS พื้นฐานไม่สนับสนุนไฟล์ที่กระจัดกระจาย NFS จะเปิดเผยการสนับสนุนที่ไม่มีอยู่ได้อย่างไร? อย่างไรก็ตามทุกวันนี้มันเป็นเรื่องยากที่จะหาระบบไฟล์โดยไม่รองรับไฟล์ที่กระจัดกระจายเช่นล่าสุด (ext3 / 4, xfs, ฯลฯ ) ระบบไฟล์ลินุกซ์ที่รองรับคุณสมบัติดังกล่าว

— shodanshok

@ สูงคุณผิด การรันddคำสั่งบนไฟล์ sparse แบบโลคัลจะให้ผลลัพธ์ที่เร็วกว่ามาก ดูที่นี่สำหรับตัวอย่าง:,

root@hubble:~# truncate -s 1G test.img root@hubble:~# dd if=test.img of=/dev/null bs=1M iflag=direct 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 0.10478 s, 10.2 GB/s

อย่างที่คุณเห็น, การอ่านไฟล์กระจัดกระจายในพื้นที่ให้ความเร็ว I / O ทางทิศเหนือของ10 GB / s

— shodanshok

@shodanshok - โอ้ฉันเข้าใจแล้วคุณกำลังดูความเร็วไม่ใช่ปริมาณที่โอน บางทีการชี้แจงว่าในคำตอบของคุณจะเป็นประโยชน์ การทดสอบแบบบัญญัติสำหรับไฟล์ที่จัดเก็บแบบเบาบางคือdu -svs ls -lแต่คุณถูกต้องที่ไม่ได้ช่วยในการส่งผ่านเครือข่าย แต่ในกรณีใดกรณีหนึ่ง (ตามที่straceยืนยัน) ddกำลังอ่านไฟล์ทั้งหมดรวมถึง 'หลุม' เป็นศูนย์ความแตกต่างจะเกิดขึ้นที่ 'ศูนย์' มาจากฝั่งเซิร์ฟเวอร์หรือฝั่งไคลเอ็นต์เท่านั้น อย่างไรก็ตามทราบ (ตามคำตอบของฉัน) ที่ NFS 4.2 ไม่สนับสนุนอย่างเต็มที่ไฟล์เบาบาง

— abligh

NFS

ใช่ NFS 4.2 รองรับไฟล์แบบเบาบาง (ดูเอกสารมาตรฐานและงานนำเสนอนี้ )

ก่อนหน้า NFS 4.2 โมเดลไคลเอ็นต์ / เซิร์ฟเวอร์ NFS สนับสนุนไฟล์แบบกระจายในแง่ที่ว่า API สนับสนุนการดำเนินการไฟล์ POSIX ทั้งหมด นี่หมายความว่าการเขียนไฟล์ sparse บนเซิร์ฟเวอร์ที่รองรับไฟล์ sparse บนระบบไฟล์สำรองส่งผลให้มีการสร้างไฟล์ sparse (แทนที่จะเก็บค่าศูนย์จำนวนมาก) แต่การอ่านไฟล์จะส่งผลให้มีการส่งจำนวนศูนย์สำหรับองค์ประกอบกระจัดกระจาย IE คำตอบคือ 'บางส่วน'

NFS 4.2 เพิ่มความสามารถสำหรับไคลเอ็นต์ในการ 'มองเห็น' รูในไฟล์และดังนั้นสำหรับเซิร์ฟเวอร์ที่ไม่ต้องส่งศูนย์ทั้งหมดเหล่านั้น จาก ID:

1.4.3.  Sparse Files

Sparse files are ones which have unallocated or uninitialized data
blocks as holes in the file.  Such holes are typically transferred as
0s during I/O. READ_PLUS (see Section 15.10) allows a server to send
back to the client metadata describing the hole and DEALLOCATE (see
Section 15.4) allows the client to punch holes into a file.  In
addition, SEEK (see Section 15.11) is provided to scan for the next
hole or data from a given location.

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

SMB

ฉันรู้เรื่อง SMB น้อยลง แต่ฉันเชื่อว่ามันรองรับไฟล์แบบเบาบางเช่นกันหากตั้งค่าความสามารถบิตที่เกี่ยวข้อง ดูที่นี่สำหรับข้อมูลเพิ่มเติม

— abligh
แหล่งที่มา