BBWC: ในทางทฤษฎีเป็นแนวคิดที่ดี แต่มีใครเคยบันทึกข้อมูลของคุณหรือไม่?


26

ฉันคุ้นเคยกับสิ่งที่ BBWC (แคชการเขียนสำรองแบตเตอรี่) ตั้งใจทำ - และก่อนหน้านี้ใช้มันในเซิร์ฟเวอร์ของฉันแม้จะมี UPS ที่ดี มีความล้มเหลวอย่างรุนแรงซึ่งไม่ได้ให้ความคุ้มครอง ฉันอยากรู้ว่าจะให้ประโยชน์ใด ๆ ในทางปฏิบัติจริงหรือไม่

(NB ฉันกำลังมองหาคำตอบเฉพาะจากผู้ที่มี BBWC และมีปัญหา / ล้มเหลวและ BBWC ช่วยกู้คืนหรือไม่)

ปรับปรุง

หลังจากข้อเสนอแนะที่นี่ฉันสงสัยมากขึ้นว่า BBWC เพิ่มคุณค่าใด ๆ

เพื่อให้มีความมั่นใจเกี่ยวกับความถูกต้องของข้อมูลระบบไฟล์จะต้องรู้ว่าเมื่อใดที่ข้อมูลมีความมุ่งมั่นในการจัดเก็บข้อมูลที่ไม่ลบเลือน (ไม่จำเป็นต้องเป็นดิสก์ เป็นที่น่าสังเกตว่ามีดิสก์จำนวนมากอยู่ที่เมื่อข้อมูลถูกส่งไปยังดิสก์ ( http://brad.livejournal.com/2116715.html ) ในขณะที่ดูเหมือนว่ามีเหตุผลที่จะสมมติว่าการปิดใช้งานแคชบนดิสก์อาจทำให้ดิสก์มีความซื่อสัตย์มากขึ้น แต่ก็ยังไม่รับประกันว่าจะเป็นเช่นนั้น

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

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

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

การรวมกันของดิสก์ที่บอกว่าเป็นพังผืดเกี่ยวกับสิ่งที่เกิดขึ้นและการสูญเสียพลังงานอย่างฉับพลันนำไปสู่การทุจริตอย่างไม่ต้องสงสัย - และด้วยระบบไฟล์ Journalling หรือ log ที่มีโครงสร้างซึ่งไม่ได้ทำ fsck เต็มหลังจากดับไฟ มีความพยายามซ่อมแซม

ในแง่ของโหมดความล้มเหลวในประสบการณ์ของฉันไฟฟ้าดับส่วนใหญ่เกิดขึ้นทันทีเนื่องจากการสูญเสียพลังงานไฟหลัก (ลดลงอย่างง่ายดายด้วย UPS และการปิดระบบที่ถูกจัดการ) ผู้คนดึงสายเคเบิลที่ไม่ถูกต้องออกจากชั้นวางแสดงถึง hyacene datacentre ที่ไม่ดี (การติดฉลากและการจัดการสายเคเบิล) มีเหตุการณ์การสูญเสียพลังงานฉับพลันบางประเภทที่ไม่ได้รับการป้องกันจาก UPS - ความล้มเหลวใน PSU หรือ VRM และ BBWC ที่มีปัญหาและอุปสรรคที่จะให้ความสมบูรณ์ของข้อมูลในกรณีที่เกิดความล้มเหลวที่นี่ การตัดสินที่หายากมากโดยขาดคำตอบที่นี่

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

อีกทางเลือกหนึ่งในการลดผลกระทบของการสูญเสียพลังงานอย่างกะทันหันคือการนำ SAN - AoE มาใช้ทำให้เป็นข้อเสนอเชิงปฏิบัติ


3
เซิร์ฟเวอร์ไฟล์ของเน็ตแอพมีเวลาหลายปีในการเขียนแคช NVRAM และฉันมีจำนวนมากที่สูญเสียพลังงานและไม่ทิ้งระบบไฟล์ของพวกเขา เป็นการยากที่จะพิสูจน์ว่ามีสิ่งใดสิ่งหนึ่งที่ช่วยกู้เพราะเมื่อมีคนได้รับการช่วยกู้ภัยพิบัตินั้นไม่ได้เกิดขึ้น คุณจะมองหาหลักฐานอะไร
MadHatter สนับสนุน Monica

คุณควรคิดเกี่ยวกับโหมดความล้มเหลวของแคชการเขียนที่มีแบตเตอรี่สำรองซึ่งเปรียบเทียบกับแคชการเขียนที่ไม่มีแบตเตอรี่
Stefan Lasiewski

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

1
ไม่มีที่หลักฐานที่แสดงว่าไม่ได้มี BBWC สามารถสูญเสียข้อมูลของคุณ พิสูจน์ให้เห็นว่า - และฉันสงสัยมากที่สุดของ sysadmins ลากยาวในระบบนี้มีเรื่องราวที่ข้อมูลผันผวนได้รับหายไปในภาวะไฟฟ้าดับ; ฉันทำอย่างแน่นอนที่สุด - จะไม่พิสูจน์ว่าการมี BBWC สามารถบันทึกข้อมูลของคุณได้ซึ่งเป็นสิ่งที่ OP ต้องการ
MadHatter สนับสนุน Monica

1
การวิเคราะห์และสร้างแบบจำลองเพิ่มเติมบางอย่างชี้ให้เห็นว่า BBWC + ไม่มีอุปสรรคใด ๆ ที่สามารถนำไปสู่ความเสียหายที่ไม่สามารถตรวจจับได้ด้วยเครื่องมือจัดกำหนดการ IO อื่น ๆ นอกเหนือจาก NOOP (ฉันอาจผิดเกี่ยวกับสิ่งนี้ แต่ได้พยายามอย่างหนัก ดูเพิ่มเติมsymcbean.blogspot.co.uk/2014/03/…
symcbean

คำตอบ:


34

แน่ใจ ฉันมีแคชแบตเตอรี่สำรอง (BBWC) และแคชการเขียนสำรองแฟลชในภายหลัง (FBWC) ป้องกันข้อมูลในเที่ยวบินหลังจากเกิดปัญหาและการสูญเสียพลังงานอย่างฉับพลัน

บนเซิร์ฟเวอร์ HP ProLiant ข้อความทั่วไปคือ:

POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

ซึ่งหมายความว่า" เฮ้มีข้อมูลในแคชการเขียนที่รอดชีวิตจากการรีบูต / การสูญเสียพลังงาน !! ฉันจะเขียนมันกลับไปที่ดิสก์ตอนนี้ !! "

กรณีที่น่าสนใจคือโพสต์ชันสูตรของฉันของระบบที่สูญเสียพลังงานระหว่างพายุทอร์นาโดลำดับของอาร์เรย์คือ:

POST Error: 1793-Drive Array - Array Accelerator Battery Depleted - Data Loss
POST Error: 1779-Drive Array Controller Detects Replacement Drives
POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

ข้อผิดพลาดของโพสต์ 1793 ไม่ซ้ำกัน - ในขณะที่ระบบกำลังใช้งานพลังงานถูกขัดจังหวะขณะที่ข้อมูลอยู่ในหน่วยความจำ Array Accelerator อย่างไรก็ตามเนื่องจากความจริงที่ว่านี่เป็นพายุทอร์นาโดพลังงานไม่ได้ถูกกู้คืนภายในสี่วันดังนั้นแบตเตอรี่อาเรย์จึงหมดลงและข้อมูลภายในหายไป เซิร์ฟเวอร์มีตัวควบคุม RAID สองตัว ตัวควบคุมอื่นมีหน่วย FBWC ซึ่งกินเวลานานกว่าแบตเตอรี่ ไดรฟ์นั้นได้รับการกู้คืนอย่างถูกต้อง ข้อมูลเสียหายบางส่วนส่งผลให้อาร์เรย์ได้รับการสนับสนุนจากแบตเตอรี่ที่ว่างเปล่า


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


5
ให้ข้อมูลดีมากงานที่ดีในการรักษาเอาท์พุทเหล่านั้นเป็นเวลานาน
deed02392

! ที่น่าสนใจ ฉันสงสัยว่า HP วางแผนที่จะรวมไว้ในตัวควบคุม Smart Arrays ซึ่งเป็นแคชที่ไม่ใช้แบตเตอรีเดียวกันกับที่ใส่ไว้ใน P2000 หรือไม่
Gabriel Talavera

4
@GabrielTalavera ใช่ HP ใช้แคชที่สำรองข้อมูลแฟลช (ตัวเก็บประจุ) ตั้งแต่ปี 2010 เป็นต้นไป ไม่มีแบตเตอรี่
ewwhite

เหมือนกันที่นี่โดยใช้ Adaptec;) ไม่ต้องกังวลอีกต่อไปและเปลี่ยนใหม่เป็นประจำ
TomTom

ขอบคุณ ewwhite - สิ่งที่ฉันกำลังมองหา คำถามหนึ่ง: เกิดอะไรขึ้นกับพลังงานของ UPS? UPS ของคุณไม่ทำงานหรือไม่เมื่อระบบทำงานในระดับต่ำ
symcbean

10

ใช่มีกรณีนั้น

เซิร์ฟเวอร์ "ไม่มี UPS" ในดาต้าเซ็นเตอร์ (ที่ดาต้าเซ็นเตอร์มี UPS) ความล้มเหลวของ PDU - ระบบขัดข้องอย่างหนัก ไม่มีการสูญเสียข้อมูล

และโดยทั่วไปก็คือ ข้อดีของ BBWC ก็คือมันอยู่ในเครื่อง มี UPS - เชื่อฉันบางครั้งมีคนทำอะไรโง่ ๆ (เช่นดึงสายผิด) UPS เป็นอุปกรณ์ภายนอก โอ้สายเคเบิลนั้น;)


ขอบคุณ TomTom ดังนั้นจึงช่วยให้คุณสามารถส่งต่อข้อมูลของคุณไปยังสิ่งกีดขวางต่อไปแทนที่จะหมุนกลับไปยังสิ่งที่ก่อนหน้า (เว้นแต่คุณจะไม่ใช้ journalling หรือเข้าสู่ระบบไฟล์ที่มีโครงสร้าง) นี่คือหนึ่งในประเด็นสำคัญที่ฉันพยายามประเมินที่นี่ ดูเหมือนว่าจะให้การเก็บรักษาที่ดีขึ้นเล็กน้อยสำหรับบทบาทไฟล์เซิร์ฟเวอร์ แต่ไม่ได้ช่วยระบบไฟล์หรือความสมบูรณ์ของ OLTP DB
symcbean

โดยอัตโนมัติ - OLTP มีโครงสร้างในการจัดการกับความล้มเหลวของเซิร์ฟเวอร์อย่างสง่างามตราบใดที่บันทึกการเขียนถูกเขียนแบบ acutally;) และเมื่อความเร็วของ IO log จำกัด , "fake writes" (รายงานโดยเขา raid คอนโทรลเลอร์) ให้ความเร็ว - แต่ความเสี่ยง ของการสูญเสียข้อมูลเว้นแต่ว่าคุณมีแคชที่ไม่ลบเลือน
TomTom

ฉันทราบว่า RedHat เป็นความเห็นที่คุณควรปิดการใช้งานอุปสรรคกับ BBWC - แม้ว่าจะปรับปรุงประสิทธิภาพให้ดีขึ้น แต่ก็ไม่มีการป้องกันในกรณีที่ไฟดับอย่างกะทันหันเช่นการสูญเสียพลังงาน - เอ้อ! access.redhat.com/site/documentation/en-US/…
symcbean

@symcbean คุณไม่ควรสูญเสียพลังงานอย่างฉับพลันในสภาพแวดล้อมของคุณ นั่นเป็นหนึ่งในสถานการณ์ที่ง่ายที่สุดในการป้องกัน เหตุใดจึงทำให้เซิร์ฟเวอร์ของคุณทำงานเหมือนอึ 100% ของเวลาสำหรับเหตุการณ์ที่เกิดขึ้นไม่บ่อยนัก?
ewwhite

1
เหตุผลทั้งหมดที่ BBWC มีอยู่จริงคือการลดปัญหาการสูญเสียพลังงานอย่างฉับพลัน ดังนั้นมันก็โอเคที่จะไม่มีอุปสรรค
TomTom

4

ฉันมี 2 กรณีที่แคชแบตเตอรี่สำรองในคอนโทรลเลอร์ HW RAID ล้มเหลวอย่างสมบูรณ์ (ใน 2 บริษัท ที่แยกต่างหาก)

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

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

หลังจากนั้นฉันพูดว่า "ไม่ต้อง" อีกครั้งเปลี่ยนเป็นมิเรอร์ดิสก์ที่ใช้ซอฟต์แวร์ (mdadm) ใน Linux + วารสารที่ใช้ fs ซึ่งมีความยืดหยุ่นที่ดีต่อการสูญเสียพลังงาน (ext4) และไม่เคยมองย้อนกลับไป ได้รับฉันใช้มันบนเซิร์ฟเวอร์ที่ไม่มีการใช้งาน IO สูงมาก


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

IME, Dell และ HP raid card จะบ่น (สมมติว่าคุณมีระบบตรวจสอบที่เหมาะสม) เกี่ยวกับแบตเตอรี่ที่ล้มเหลวใน BBWC
mfinni

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

4

ดูเหมือนว่าจะจำเป็นต้องมีคำตอบสำหรับคำถามที่สอง ...

ฉันเพิ่งมีโฮสต์ VMware ESXi แบบสแตนด์อโลนที่สูญเสียไดรฟ์ในอาร์เรย์ RAID 5 อาร์เรย์ที่เสื่อมโทรมส่งผลกระทบต่อประสิทธิภาพการทำงานที่ VM และระดับแอปพลิเคชัน

Smart Array P410i in Slot 0 (Embedded)    (sn: 5001438011138950)

   array A (SAS, Unused Space: 0  MB)

      logicaldrive 1 (1.6 TB, RAID 5, Recovering, 42% complete)

      physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
      physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, Rebuilding)
      physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK)
      physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK)
      physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 300 GB, OK)
      physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 300 GB, OK)
      physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 300 GB, OK)
      physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 300 GB, OK, spare)

บุคคลด้านไอทีที่ บริษัท นี้ไม่ทราบว่าไดรฟ์ล้มเหลวและฮาร์ดรีเซ็ตเซิร์ฟเวอร์ ( เพื่อให้ดีขึ้นทั้งหมดหรือไม่ )

ผลที่น่าสนใจของการทำเช่นนี้กับอาเรย์ที่ถูกบุกรุกด้วยเครื่องเสมือนที่ไม่ว่างที่ทำงานบนยอดคือ:

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

ดังนั้นแม้ว่าระบบจะหยุดชะงักในทันทีข้อมูลในเที่ยวบินได้รับการคุ้มครองโดย BBWC เครื่องเสมือนกู้คืนได้อย่างถูกต้องและระบบอยู่ในสภาพดี


3

นอกเหนือจาก "การบันทึกข้อมูลของคุณ" มันยังดีต่อสิ่งอื่น พวกเขายังดีในการบัฟเฟอร์การเขียน (ในแคช) เพื่อปรับปรุงประสิทธิภาพของระบบย่อย IO โดยทำให้ disk-write-queue ต่ำ สิ่งนี้มีความสำคัญอย่างยิ่งสำหรับเซิร์ฟเวอร์ที่ประสิทธิภาพการโต้ตอบเป็นสิ่งสำคัญยิ่งตัวอย่างเช่น Citrix XenApp หรือ Windows Terminal Services

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


"ฉันคุ้นเคยกับสิ่งที่ BBWC (แคชการเขียนสำรองแบตเตอรี่) ตั้งใจจะทำ"
symcbean

2
คุณยังกล่าวอีกว่า: "ฉันอยากรู้อยากเห็นว่าจริง ๆ แล้วมันมีประโยชน์ในทางปฏิบัติจริง ๆ ฉันให้คุณ (และผู้อ่านในอนาคต) อย่างเป็นรูปธรรม จากคำถามของคุณไม่ชัดเจนเลยว่าคุณรู้เกี่ยวกับประโยชน์นี้ และคำตอบของฉันก็ไม่ผิด
mfinni

ดังนั้นคะแนนที่คุณทำแตกต่างจากแคชเขียนที่ลบเลือนได้อย่างไร
symcbean

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

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