จะเกิดอะไรขึ้นเมื่อฉันฆ่า 'cp' ปลอดภัยหรือไม่และมีผลกระทบใด ๆ


23

อะไรคือผลที่ตามมาของระบบไฟล์ ext4 เมื่อฉันยุติcpคำสั่งการคัดลอกโดยพิมพ์Ctrl+ Cในขณะที่มันกำลังทำงานอยู่

ระบบไฟล์เสียหายหรือไม่? พื้นที่ของพาร์ติชั่นครอบครองโดยไฟล์ที่คัดลอกไม่สมบูรณ์ยังคงสามารถใช้งานได้หลังจากลบมันหรือไม่?

และที่สำคัญที่สุดคือการยกเลิกcpกระบวนการเป็นสิ่งที่ปลอดภัยที่จะทำ?


1
โปรดทราบว่าในขณะที่คำตอบนั้นถูกต้องสำหรับ ext4 ระบบไฟล์ที่ไม่มีการทำเจอร์นัลอาจไม่ปลอดภัย
Ave

3
@Ave Journaling ไม่มีส่วนเกี่ยวข้องกับสิ่งนี้ syscalls เป็นอะตอมโดยไม่คำนึงถึงระบบไฟล์ที่คุณใช้ การจดบันทึกมีประโยชน์ในสถานการณ์ที่อาจสูญเสียพลังงานอย่างฉับพลัน
ป่า

คำตอบ:


22

วิธีนี้ปลอดภัยที่จะทำ แต่โดยธรรมชาติคุณอาจยังทำสำเนาไม่เสร็จ

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

open("/home/user/hello.txt", O_RDONLY)           = 3
open("/mnt/hello.txt", O_CREAT|O_WRONLY, 0644)   = 4
read(3, "Hello, world!\n", 131072)               = 14
write(4, "Hello, world!\n", 14)                  = 14
close(3)                                         = 0
close(4)                                         = 0

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

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


2
@qwr นั่นน่าจะเป็นส่วนหนึ่งของไลบรารี glibc ไม่ใช่cpตัวของมันเอง มันมีฟังก์ชั่นการเข้าถึงไฟล์ต่าง ๆ ที่ใช้ภายในเป็นค่า
ป่า

2
คำตอบที่ดี! ฉันไม่เคยรู้เลยว่ามีความล่าช้าในการยกเลิกcpหลังจาก SIGKILLING ถึงแม้ว่าในขณะที่จัดการกับไฟล์ขนาดใหญ่ ... บางทีระยะเวลาของการดำเนินการอะตอมมิกเหล่านี้ของอินเทอร์รัปต์นั้นสั้นเกินไป คำอธิบายเดียวกันนี้ใช้ได้กับการฆ่าddและกระบวนการอ่าน / เขียนดิสก์อื่น ๆ หรือไม่?
Seninha

1
@Seninha การดำเนินการค่อนข้างสั้นเนื่องจากการเข้าถึงถูกแคชดังนั้นคุณสามารถคัดลอกข้อมูลได้มากขึ้นต่อวินาทีกว่าที่ไดรฟ์ของคุณสามารถจัดการได้จริง หากไฟล์มีขนาดใหญ่มากและอยู่บนสื่อที่ช้าก็จะทำให้แคชสามารถเติมและฆ่ากระบวนการอาจใช้เวลาสักครู่ สำหรับการฆ่าddนั้นขึ้นอยู่กับสิ่งที่bsคุณตั้งไว้ หากเป็นเพียง 512 (ค่าเริ่มต้น) ก็ควรจะยุติอย่างรวดเร็ว หากมีขนาดใหญ่ขึ้นอาจใช้เวลานานขึ้นเล็กน้อย
ป่า

3
@qwr 128kb ชิ้นเป็นค่าเริ่มต้นเดินสายใน coreutils เมื่ออ่านจาก blockdevices นี้จะทำในความพยายามที่จะลด syscalls การวิเคราะห์ได้รับในแหล่ง coreutils: git.savannah.gnu.org/cgit/coreutils.git/tree/src/ioblksize.h
Fiisch

1
@AndrewHenle บางทีฉันควรจะบอกว่ามันเป็นเมตาดาต้าระบบแฟ้มซึ่งเป็นอะตอม คุณถูกต้องว่าการเขียนอาจเป็นบางส่วน
ป่า

20

เนื่องจากcpเป็นคำสั่ง userspace สิ่งนี้จึงไม่ส่งผลต่อความสมบูรณ์ของระบบไฟล์

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


14
ทำไมต้องลงคะแนน เพียงเพราะมัน schily?
Stephen Kitt

6
ดูเหมือนจะมีคนอย่างน้อยหนึ่งคนที่ปฏิเสธคำตอบของฉันทั้งหมด คุณรู้วิธีที่จะค้นหาว่าใครลงคะแนนบ้าง
Schily

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

1
มันจะค่อนข้างน่าเศร้าถ้าโปรแกรม userspace นั้นสามารถทำลายความสมบูรณ์ของระบบไฟล์ได้ หมายเหตุ: แน่นอนสามารถมีได้มีและจะมีข้อบกพร่องในการใช้งานระบบไฟล์ หมายเหตุ # 2: นอกจากนี้แน่นอนว่าโปรแกรมผู้ใช้งานที่ทำงานด้วยสิทธิ์ยกระดับ (เช่นCAP_SYS_RAWIOใน Linux หรือเทียบเท่าในระบบปฏิบัติการอื่น ๆ ) ที่ให้พวกเขาเข้าถึงอุปกรณ์พื้นฐานของระบบไฟล์โดยตรง (เช่นsudo dd if=/dev/urandom of=/dev/sda1) อาจทำให้เกิดความเสียหายได้ทุกประเภท
Jörg W Mittag

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