ไม่ควรใส่ SSD อะไร

ฉันซื้อ SSD และฉันจะตั้งค่าระบบเดสก์ท็อปของฉันด้วยการติดตั้ง Linux ใหม่อย่างสมบูรณ์

เป็นที่ทราบกันดีว่า SSD นั้นเร็ว แต่มีข้อเสีย: จำนวนการเขียน (ต่อบล็อก?) มี จำกัด

ดังนั้นฉันจึงคิดว่าข้อมูลใดควรอยู่ที่ SSD และที่ไดรฟ์ HDD โดยทั่วไปฉันคิดว่าข้อมูลที่เปลี่ยนแปลงบ่อยควรอยู่ใน HDD และข้อมูลที่ไม่เปลี่ยนแปลงบ่อยสามารถใส่ใน SSD ได้

• ตอนนี้ฉันอ่านคำถามนี้โดยมีสถานการณ์คล้ายกัน ในคำตอบที่เขียนไว้: "ไดรฟ์ SSD เหมาะอย่างยิ่งสำหรับพื้นที่สว็อป ... "

  ทำไม SSD จึงเหมาะอย่างยิ่งสำหรับพื้นที่สว็อป? ตกลงฉันเห็นว่ามีศักยภาพสูงในการเพิ่มประสิทธิภาพของระบบ แต่ไม่สลับข้อมูลเปลี่ยนบ่อยและด้วยเหตุนี้จะมีการเขียนจำนวนมากบน SSD ทำให้อายุการใช้งานของ SSD สั้นลง

• แล้วไดเร็กทอรี / var ล่ะ? เนื้อหาของมันไม่เปลี่ยนแปลงบ่อยเกินไปใช่ไหม จะเป็นการดีถ้าจะวางไว้บน HDD หรือไม่?

• มีข้อมูลอื่นใดที่ไม่ควรอยู่ใน SSD หรือไม่?

หากคุณกังวลเกี่ยวกับรอบการเขียนคุณจะไม่ไปไหนเลย

คุณจะมีข้อมูลใน SSD ที่เปลี่ยนแปลงบ่อย บ้านของคุณการกำหนดค่าแคชเบราว์เซอร์ของคุณหรือแม้แต่ฐานข้อมูล (ถ้าคุณใช้) ทั้งหมดควรอยู่ใน SSD: ทำไมคุณจะมีอย่างอื่นถ้าไม่เพิ่มความเร็วสำหรับสิ่งที่คุณทำบ่อยๆ

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

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

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

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

เช่นเดียวกับสื่อบันทึกข้อมูลทั้งหมด SSD จะล้มเหลวในบางช่วงเวลาไม่ว่าคุณจะใช้หรือไม่ก็ตาม คุณควรพิจารณาให้เชื่อถือได้เหมือนกับ HDD ซึ่งไม่น่าเชื่อถือเลยดังนั้นคุณควรทำการสำรองข้อมูล

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

• ไฟล์ที่ต้องอ่านมากและเขียนไปไม่ค่อย (เช่นระบบปฏิบัติการและโปรแกรม) น่าจะเป็นที่ชัดเจนที่สุดในการย้ายไปยัง SSD
• ไฟล์ที่เขียนครั้งเดียวและอ่านหลายครั้งในอัตราข้อมูลคงที่ซึ่ง HDD เร็วพอ (เช่นเพลงวิดีโอ) น่าจะอยู่ที่นั่น พวกเขามักจะไม่ได้แก้ไข แต่พิจารณาว่าพวกเขาจะเขียนไปยังจำนวนมากของภาค
• ไฟล์ขนาดเล็กที่มีการแก้ไขจำนวนมาก (เช่นไฟล์ชั่วคราวบางไฟล์) นั้นซับซ้อนกว่า ตัวอย่างเช่นเมื่อกำหนดขนาดเซกเตอร์ 512 ไบต์คุณสามารถเขียนทับไฟล์เซกเตอร์เดียว 20,000,000 ครั้งก่อนที่จะ "บริโภค" จำนวนการเขียนที่เท่ากันเหมือนกับการเขียนไฟล์ 1 GiB หนึ่งครั้ง หาก SSD ดูแลระดับการสึกหรอสิ่งเหล่านี้ควรเทียบเท่า

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

นอกจากคำตอบทั้งหมดที่นี่มีเคล็ดลับเล็ก ๆ ที่ฉันชอบ ฉันเริ่มใช้ ramdisk อีกครั้งกับ SSD เพื่อให้เอฟเฟกต์การสึกหรอช้าลงเล็กน้อย ฉันใช้มันเพื่อแคชเบราว์เซอร์ (ทั้งโปรไฟล์เบราว์เซอร์ทั้งหมด), temps ต่างๆ, บันทึกที่ไม่จำเป็นบางอย่างและอื่น ๆ (ผ่าน symlink)

ramdisk ของฉันถูกตั้งค่าเป็น fstab ดังนี้:

tmpfs       /mnt/ramdisk tmpfs   nodev,nosuid,size=512M   0 0

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

ความเร็วของระบบจะเพิ่มขึ้นเล็กน้อยและบันทึกรอบการเขียนบางส่วน สิ่งที่ดีอาจเป็นงาน cron ทำ rsync ทุก ๆ 15 นาที?

#!/bin/bash

### BEGIN INIT INFO
# Provides:          Ramdisk control
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 6
# Short-Description: Start/stop script at runlevel change.
# Description:       Ramdisk auto backup and restore
### END INIT INFO

PATH=/sbin:/bin:/usr/sbin:/usr/bin
USER="user1"
RDISK=/mnt/ramdisk
BACKUP=/opt/
#/home/$USER/BackUps/

#echo "$(date) $1" >> $BACKUP/rd.log

case "$1" in
    stop)
        rsync -aE --delete $RDISK $BACKUP
        ;;
    start|force-reload|restart|reload)
        #restore ramdisk
        cp -rp $BACKUP/ramdisk/* $RDISK 2> /dev/null
        ;;
    *)
        echo 'Usage: /etc/init.d/ramdisk {start|reload|restart|force-reload|stop|status}'
        echo '       stop                       - backup ramdisk data'
        echo '       start|*                    - restore ramdisk data from backup'
        echo '       - default backup location is /xxxxx'
        exit 1
        ;;
esac


exit $?

คำเตือนเล็กน้อยสำหรับผู้ใช้ Ubuntu ไม่ใช้ / สื่อ / ผู้ใช้ / โฟลเดอร์สำหรับการสำรองข้อมูล ramdisk เนื่องจากได้รับการรีเซ็ตโดยการอัปเดตบางอย่างดังนั้นฉันจึงสูญเสียข้อมูลโปรไฟล์เป็นระยะ ๆ เช่นเดียวกันกับ Ubuntu ฉันมีปัญหาในการสร้าง ramdisk bakups ในโฟลเดอร์ที่เข้ารหัส

เห็นด้วยกับคนอื่น ๆ คุณควรใส่ทุกอย่างสวยมากยกเว้นไฟล์ที่มีขนาดใหญ่มาก (วิดีโอ) เพื่อหลีกเลี่ยงการเสียพื้นที่ SSD ที่มีราคาแพง

อย่างไรก็ตามคุณควรตรวจสอบให้แน่ใจว่าได้เปิดใช้งานTRIM :

• SSD ของคุณรองรับ TRIM
• พาร์ติชันของคุณอยู่ในแนวเดียวกับ EBS
• ระบบไฟล์ของคุณรองรับ TRIM ในระบบไฟล์ของคุณ (โดยปกติจะเป็น ext4)
• คุณใช้fstrimกฎเกณฑ์ (อาจเป็น cron ทุกสัปดาห์)
• คุณให้พื้นที่ดิสก์ว่างอย่างน้อย 25% [ 1 ]

อย่าลืมสำรองข้อมูลของคุณ

UPDATE:

• Arch แนะนำว่าอย่าวาง swap บน SSDเพื่อหลีกเลี่ยงการสึกหรอ

หากคุณไม่ต้องการใช้เวลาในการจัดส่งข้อมูลของคุณผ่าน HDD และ SDD คุณสามารถใช้ SDD ของคุณเป็นแคชได้

• L2ARC cache บน ZFS (Solaris, * BSD)
• Bcache (Linux) มันเป็นรหัสอัลฟ่าดังนั้นอาจไม่น่าเชื่อถือ

ฉันขอโทษคำตอบที่ไม่ดีแน่นอนคุณสามารถและควรสร้างระบบที่รวดเร็วมากและยังคงย้ายโฟลเดอร์ที่เขียนเป็นส่วนใหญ่ไปยัง HDD ย้าย / tmp ไปที่ / tmpfs หรือสร้างพาร์ติชัน / tmp บน HDD เช่นกันและย้ายไปยัง HDD และสร้าง symlink ในโฟลเดอร์ดั้งเดิมสำหรับ / var / log / var / spool และ / var / tmp (อย่าใส่ / var / tmp บน tmpfs เนื่องจากมี เป็นข้อมูลที่สามารถเข้าถึงได้ในทุก ๆ การรีบูต) ย้ายไปที่ HDD และสร้าง symlink สำหรับ ~ / Downloads ~ / Videos ~ / Music ~ / .config ~ / .cache ~ / .thunderbird ~ / .mozilla ~ / .googleearth ~ / .ACEStream และคนอื่น ๆ ที่คุณรู้จักหรือหาเขียนบ่อย แคช (มักจะค้นหาว่าแคชของเบราว์เซอร์ของคุณอยู่ที่ไหนและย้ายไปที่ HDD Chrome และ Firefox ที่ถูกปกคลุมด้วยสิ่งเหล่านี้ที่ฉันเชื่อ หากคุณต้องการแก้ไขไฟล์วิดีโอคุณสามารถย้ายไปที่ ssd มิฉะนั้น 99% ของเอกสารและสื่อไม่มีประโยชน์ใน SSD เช่นเดียวกับ HDD ที่ใช้น้อยกว่าโดย systen เทคนิคเหล่านี้มีผลกระทบในทางลบต่อประสิทธิภาพและความแตกต่างอย่างมากในความทนทานของ SSD ย้ายไปที่ HDD และสร้าง symlink สำหรับโฟลเดอร์ cloud ของคุณ (เช่นดรอปบ็อกซ์) พิจารณาย้าย / var / www ด้วยหากคุณกำลัง apaching ตอนนี้คุณมีระบบที่เร็วมากซึ่งแทบจะไม่มีความแตกต่างของความเร็วและมีการสึกหรอน้อยลง