Gnome, คัดลอกไฟล์ไปยัง USB หยุดที่ 100% หรือใกล้เคียง


29

ฉันเคยมีปัญหาที่คล้ายกันมาก่อน แต่ฉันจำไม่ได้ว่าฉันแก้ไขมันได้อย่างไร

เมื่อฉันพยายามที่จะคัดลอกบางสิ่งไปยัง USB stick ด้วย FAT มันจะหยุดลงใกล้ที่สุดบางครั้งก็อยู่ที่ 100% และแน่นอนเมื่อฉันถ่ายโอนเมมโมรี่สติ๊กที่อื่นมันไม่มีไฟล์ที่สมบูรณ์ (ไฟล์เป็นภาพยนตร์!)

ฉันพยายามเมานต์อุปกรณ์ด้วย mount -o flush แต่ฉันได้รับปัญหาเดียวกัน

นอกจากนี้ฉันยังฟอร์แมตแท่ง USB ด้วยพาร์ทิชัน FAT ใหม่ ...

ความคิดใดที่ฉันเย็นชา?

ps ฉันเชื่อว่ามันไม่เกี่ยวข้องกับระบบปฏิบัติการซึ่งก็คือ Debian และฉันเชื่อว่าการจัดการกับไดรฟ์ SSD ไม่ทำให้ติดขัด


3
บางที่ฉันได้พบคำอธิบายเรื่องต่อไปนี้ ในกรณีการคัดลอกทำผ่านหน่วยความจำในการใช้งานและ idicator แสดงกระบวนการอ่านข้อมูลจากไดรฟ์ แต่กระบวนการ wrighting นั้นยาวกว่าโดยเฉพาะอย่างยิ่งกับ USB-stick (อาจช้ากว่า 100 เท่า: เช่น 2Mb / วินาทีซึ่งสามารถอ่านได้ 200Mb / วินาทีในการอ่าน) และมากกว่านั้นถ้าคุณใช้ระบบไฟล์แบบ FAT หรือ NTFS ภายใต้ linux . ดังนั้นพยายามรอธุรกรรมสิ้นสุดแม้ว่าหยุดที่ 100% แต่ไม่ปิด (ซึ่งควรระบุว่าเสร็จสิ้น)
Costas

เพียงแค่สงสัยว่ามันเป็นไปได้ที่จะตรวจสอบความคืบหน้าในสถานการณ์นั้นหรือไม่?

พยายามจัดรูปแบบ pendrive ด้วยตัวเลือกเขียนทับข้อมูลที่มีค่าเป็นศูนย์มันทำงานบน My trancend 8GB pendrive
Akshay Daundkar

สำหรับใครก็ตามที่พบปัญหานี้เพียงแค่ฟอร์แมตไดรฟ์ของคุณเป็น NTFS
Ricky Boyce

คำตอบ:


37

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

ดังนั้นน่าเสียดายที่โปรแกรมไม่สามารถบอกคุณได้ว่าต้องใช้เวลานานแค่ไหนในการล้างบัฟเฟอร์เนื่องจากไม่รู้

หากคุณต้องการลองใช้เล่ห์เหลี่ยมผู้ใช้ระดับสูงคุณสามารถลดขนาดของบัฟเฟอร์ที่ Linux ใช้โดยการตั้งค่าพารามิเตอร์เคอร์เนลvm.dirty_bytesเป็นขนาดเช่น15000000(15 MB) ซึ่งหมายความว่าแอปพลิเคชันไม่สามารถรับได้เกินกว่า 15MB ก่อนความคืบหน้าจริง (คุณสามารถเปลี่ยนพารามิเตอร์เคอร์เนลได้ทันทีด้วยsudo sysctl vm.dirty_bytes=15000000แต่การทำให้พารามิเตอร์เหล่านั้นอยู่ในการรีบูตต้องเปลี่ยนไฟล์กำหนดค่า/etc/sysctl.confซึ่งอาจเฉพาะเจาะจงกับ distro ของคุณ)

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

แต่อย่าตั้งมันเล็กเกินไป! ฉันใช้ 15MB เป็นค่าคร่าวๆที่เคอร์เนลสามารถล้างบัฟเฟอร์ไปยังฮาร์ดไดรฟ์ปกติใน 1/4 ของวินาทีหรือน้อยกว่า มันทำให้ระบบของฉันไม่รู้สึก "ล้าหลัง"


ฉันกำลังมองหาการแก้ไขปัญหานี้เป็นเวลาหนึ่งปีหรือมากกว่านั้นฉันคิดว่ามันเป็นเพียงข้อบกพร่องในลินุกซ์ ขอบคุณมาก.
Sidahmed

1
Linux noob ที่นี่มีคนโพสต์วิธีเปลี่ยนค่า <dirty_bytes> หรือไม่
Brofessor

@Brofessor โอ้ขอโทษฉันควรจะอธิบายด้วยชื่ออย่างเป็นทางการแทน / รายละเอียด proc อัปเดตคำตอบแล้ว
dataless

1
สิ่งนี้คล้ายกับunix.stackexchange.com/questions/107703/… --- ควรได้รับการแก้ไขแล้ว แต่เชื่อฉันเถอะไม่ใช่ ฉันต้องเพิ่มไปที่ Ubuntu 18.04 เพื่อหยุดพฤติกรรมตลก ...
Rmano

ใช้งานได้กับ Fedora 30 ด้วย ฉันประหลาดใจที่เห็นพฤติกรรมโง่ ๆ เช่นนี้แม้ใน Linux distros สมัยใหม่
sziraqui

0

คำถามเก่า แต่ดูเหมือนว่าปัญหายังคงเกิดขึ้น การตั้งค่าบัฟเฟอร์เป็น 15MB ตามที่แนะนำที่นี่ไม่ทำงานบน Ubuntu 19.04 และทำให้ระบบของฉันหยุดชะงัก

ฉันพยายามคัดลอกไฟล์ 1.5GB ไปยังไดรฟ์ FAT32 16GB ที่ว่างเปล่า (ฟอร์แมตใหม่) ฉันปล่อยให้มันวิ่งประมาณ 10 นาทีเพื่อดูว่ามันจะเสร็จโดยไม่มีโชคหรือไม่

การฟอร์แมตเป็น NTFS ทำให้การดำเนินการเสร็จสิ้นในเวลาน้อยกว่า 10 วินาที ฉันไม่รู้ว่าทำไมเรื่องนี้ถึงสำคัญเพราะ FAT32 ควรอนุญาตอะไรที่ต่ำกว่า 2GB แต่ดูเหมือนว่าจะทำงานได้ดี ไม่ใช่การแก้ไขที่สมบูรณ์แบบสำหรับไดรฟ์ที่คุณต้องการใช้กับ MacOS แต่เป็นวิธีแก้ปัญหาที่ง่ายสำหรับกรณีการใช้งานอื่นทั้งหมด ฉันจินตนาการว่า exFAT จะทำงานเหมือนกัน แต่ฉันไม่ได้ทดสอบ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.