เว็บไซต์ AnandTech ค้นพบว่า Android 4.3 Jelly Bean ที่เพิ่งออกเมื่อสัปดาห์ที่แล้ว รองรับคำสั่ง TRIM หรือการบอกระบบปฏิบัติการว่าบล็อคข้อมูลไหนใน SSD/eMMC ที่ไม่ใช้เก็บข้อมูลแล้ว สามารถนำบล็อคนี้มาใช้เก็บข้อมูลอย่างอื่นได้
AnandTech ทดสอบแล้วพบว่าอุปกรณ์ตระกูล Nexus สามรุ่นได้แก่ Nexus 7 รุ่นแรก, Nexus 7 รุ่นที่สอง และ Nexus 4 ที่อัพ 4.3 แล้วมีฟีเจอร์นี้ ช่วยให้ประสิทธิภาพด้าน I/O ดีขึ้นมาก ต่างไปจากการใช้ระบบปฏิบัติการรุ่นก่อนหน้าที่ใช้ไปนานๆ หรือเก็บข้อมูลเยอะๆ แล้วระบบจะเริ่มช้าลง
รายละเอียดทางเทคนิคอ่านได้จากต้นฉบับครับ
ที่มา - AnandTech
Comments
ฟีเจอร์ในฝัน
Windows Phone 8 นี่มีมั่งรึยังเนี่ย เห็น Windows RT มีแล้ว
ยี่ห้ออื่นจะมีฟีเจอร์นี้อยู่แล้วแบบ Bluetooth LE รึเปล่าเนี่ย?
Dream high, work hard.
ดีครับ ฟีเจอร์นี้ ผมจำได้ว่าเคยบ่นเอาไว้ในนี้แหละว่าไฟล์เยอะๆ แล้วระบบโดยรวมช้าลง แล้วมีคนบอกว่ามือถือใช้แฟลชไม่ได้ใช้ฮาร์ดดิสก์ ไฟล์เยอะไม่ช้า
สรุปคือไฟล์เยอะมันก็ยังช้าอยู่จริงๆ สินะ
ผมก็ยังไม่เชื่อคนพวกนั้นอยู่ดี
เป็น flash แต่มันก็มี fragment อยู่ดี
เวลาอ่านก็ต้องอ่านหลายเที่ยวกว่าจะครบไฟล์
ก็แค่ไม่มีoverheadในการไปอ่านblockอื่นๆเพื่อเอาdataมาเรียงกันตอนอ่าน
flash storage ไม่มี fragmentation ครับ มีแต่ปัญหาเรื่อง write นี่แหละ
ก่อนอื่นต้องเข้าใจก่อนว่า flash storage ไม่ได้ใช้ planar ที่เป็นจานหมุนจานเดียว-สองจารและมีหัวอ่านแบบ harddisk ปกติ แต่จะประกอบด้วย NAND เล็กๆ หลายๆตัว(ประมาณ 8) ซึ่ง NAND Flash มันเป็นการทำงานแบบ electrical(แบบRAM) ไม่ใช่ mechanical ฉะนั้นจุด data ทุกจุดบน NAND จะทำงานได้ความเร็วเท่ากันหมด และจะถูกควบคุมด้วย controller อีกที ซึ่ง SSD จะเร็วหรือช้าก็ขึ้นอยู่กับตัว controller ครับ
ในการเขียนไฟล์หนึ่งๆ controller จะกระจายไฟล์ที่เขียนอยู่ในให้ NAND แต่ละตัวในอัตราที่พอๆกัน(ให้นึกถึง RAID 0) เพื่อให้สามารถอ่านเขียนได้เร็วที่สุด(load balance) อาจจะเรียกรูปแบบนี้ว่า fragmentation(?) ก็ได้ แต่มันไม่ได้เป็นข้อเสียครับ ไม่ได้เหมือน HDD fragmentation
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
ผมบอกเองครับ
กรณีนี้ไม่เกี่ยวกับไฟล์เยอะไม่เยอะแล้วช้าครับ และไม่เกี่ยวข้องกับ read speed เลย แต่มันเกี่ยวกับการลบไฟล์ออกแล้วจะเขียนไฟล์ทับตรงจุดนั้น ที่จะต้อง erase พื้นที่ตรงที่จะเขียนก่อน(ทาง logical) แล้วถึงจะเขียนได้ครับ (overwritten cycle)
แต่ก็มีส่วนบ้างเนื่องจากการที่เนื้อที่ว่างยิ่งน้อย โอกาสที่จะเขียนทับตรงจุดที่ลบไปยิ่งมีโอกาสสูง แต่ไม่ได้มีผลกับ read speed แต่อย่างใด
การมี TRIM ช่วยให้เวลาลบ ระบบจะช่วย erase พื้นที่ตรงนั้นให้โดยอัตโนมัติ(ทาง logical) ทำให้ไม่ต้องมี erase เวลาเขียนใหม่ ทำให้ I/O , throughput ไม่ติดขัดเวลา write
ฉะนั้นขอยืนยันอีกรอบนะครับ ไฟล์เยอะๆไม่ได้ทำให้ระบบบน SSD ช้าเพราะส่วนมากเป็นการ read ไม่ใช่ write ที่มันช้าเพราะ CPU เอาเวลาไปคำนวนไฟล์ต่างๆเช่น thumbnail/render เยอะขึ้นมากกว่า
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
+1
โอ้ ข้อมูลเยอะขนาดนี้ผมเชื่อครับ แต่เห็นด้านบนบอกว่า "มือถือใช้แฟลชไม่ได้ใช้ฮาร์ดดิสก์ ไฟล์เยอะไม่ช้า"(ไม่เป็นความจริง) เขาก็พูดถูกนะครับ สรุแคือช้า แต่ช้าด้วยคนละสาเหตุกันเท่านั้นเอง
ขอบคุณครับ เดี๋ยวต้องอ่านเพิ่มละ ข้องใจการ access อยู่สำหรับบางเงื่อนไข
หลักๆมันเป็นเรื่องของข้อจำกัดของ flash storage ที่เขียนข้อมูลทับไม่ได้ และถ้าจะลบ(เพื่อที่จะเขียนใหม่)ต้องลบทั้ง block เลย(ซึ่งอาจจะมีข้อมูลจากหลายๆไฟล์รวมกันหรือไฟล์เดียวก็ได้) จึงมี GC,TRIM,GC+TRIM เข้ามาช่วยครับ
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
โอเค ตอนนี้ผมพอจะเข้าใจมากขึ้นถึงสาเหตุของการช้าแล้วครับ
แต่คือกรณีที่ผมบอก อันนี้มันช้าไปจรถึงการถอนการติดตั้งแอพเลยครับ รวมถึงการสแกนไฟล์ (พวกแอพ Cleanup ต่างๆ) ก็ทำได้ช้าขึ้นอย่างเห็นได้ชัด ผมเข้าใจว่าไฟล์เล็กๆ จำนวนมาก มันก็ยังสแกนได้ช้าอยู่ เพราะมันต้องอ่านรายละเอียดเล็กๆ น้อยๆ ของไฟล์หลายครั้ง
แต่ที่ยังไม่เข้าใจคือทำไมการมีไฟล์จำนวนมากพวกนี้มันไปทำให้การถอนการติดตั้งแอพมันช้าลงด้วยครับ
บางทีอาจจะเป็นบั๊ก eMMC บางรุ่นแบบที่ข้างล่างบอกก็ได้ครับ เพราะที่สังเกตุมันก็ไม่ได้เป็นกันทุกเครื่อง
การ scan ไฟล์นี่ไฟล์เยอะมันทำให้ช้าอยู่แล้วครับ เพราะต้อง scan ไฟล์ทุกไฟล์ ปริมาณข้อมูลที่มากขึ้นจึงต้องใช้เวลาที่มากขึ้นตามไปด้วย
เรื่องถอนการติดตั้งผมก็ไม่แน่ใจครับ เพราะปกติแล้วการลบไฟล์นั้น OS จะลบแค่ link ของตัวเอง ไม่ได้ไปสั่งให้ eMMC/SSD/harddisk ทำการลบจาก LBA ทำให้ขึ้นตอนเบื้องต้นจะไม่มีการทำงานของ eMMC(แต่จะไปหนักตรงการทำ GC ตอน idle/การเขียนทับแทน) ยกเว้นจะส่งคำสั่ง TRIM ไปด้วย แล้ว GC ทำงานทันที (คงไม่มั้ง)
แต่ถ้าอาการช้าหรือค้างหรือการกระตุกขณะอ่านไฟล์อย่างเดียวถ้าไม่เกี่ยวกับ CPU อาจมีสาเหตุมาจาก dead block/controller bug ครับ อาการที่ 2 สำหรับ SSD อาจจะ upgrade firmware ได้ แต่สำหรับ eMMC น่าจะทำอะไรไม่ได้ครับ
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
ถ้าถึงกับกระตุก มันเป็นบั๊กของ eMMC บางรุ่นครับ ผมโดนมากับตัว
ต้อง trim ตลอดถ้าcopy file ลงเครื่อง
ส่วนรุ่นอื่นๆช้าแบบไม่เห็นอาการมากนัก
trim ที่มากับ 4.3 นี้ผมมองว่าเป็นการแก้บั๊กข้างต้น
คนที่ไม่เป็นก็ได้อานิสงค์ไปด้วย
Android 4.3 เล่น Ingress ลื่นขึ้นจริงๆครับ
+1
I need healing.
ios มีเปล่า
จริงๆเรื่อง TRIM นี่ Anandtech อธิบายผิดนะครับ
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
ผิดยังไงอะครับ รบกวนอธิบาย
Pitawat's Blog :: บล็อกผมเองครับ
หลักๆความช้ามันจะอยู่ที่การ allocation โดย GC และ overwritten cycle (read block ลง cache , erase block, modify block บน cahce โดยเอาข้อมูลชุดเก่าถ้ามี+ชุดใหม่,write block) ที่ทำให้เสียความเร็วไปเยอะโดยทำถึง 4 step แทนที่จะเป็น 1 step (write)ครับ และ TRIM จะมาช่วยเรื่องนี้(หรือทำให้แย่กว่าเดิมถ้าไปทำงานขัดกับ GC บางตัว เช่น GC ของ Sandforce controller บางตัว เนื่องจากตัว controller ใช้การบีบอัดข้อมูลเข้ามาเกี่ยวข้อง หรือบางทีตัว Controller ก็ควบคุมคำสัง TRIM ได้แย่เป็นต้น)
แต่ Anandtech ดันไปเน้นเรื่องความช้าจากการ mapping ของ controller ที่มากขึ้นซึ่งจริงๆแล้วไม่ได้มีผลสำคัญ(insignificant)แต่อย่างใดครับ
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)