Hi, After some more testing, the SSD's write cache does not appear to be a big issue on power failure, in general anyway.
As it turns out, the echo "Testing..." > /mnt/kd/test, "pull plug" test fails more often because of the Linux fs buffers not the SSD disk write cache. So, changing the test to: $ echo "Testing..." > /mnt/kd/test ; sync (pull the power plug) The following SATA drives passed: (ie, /mnt/kd/test existed on reboot) -- WDC SSD-M0004S-7100 (mSATA) 4 GB SLC ADATA SP600 (2.5") 32 GB MLC SanDisk SSD U110 (2.5") 32 GB MLC -- The following SATA drive failed: (ie, /mnt/kd/test did not exist on reboot) -- Emphase D1VHSD001G0 (DOM) 2 GB SLC -- I am currently testing the "SanDisk SSD U110" series, so far looks very good, more later in a separate thread. Lonnie On Oct 18, 2014, at 10:05 AM, Lonnie Abelbeck <[email protected]> wrote: > Hi, > > I'd like to start a discussion on the SATA Drive "write cache" and whether it > should be disabled in AstLinux. > > In the past Compact Flash (CF) was the most commonly used AstLinux flash > storage, but today some of the newer x86 hardware no longer support CF and > are moving to mSATA and 2.5" SATA. > > I did a survey of my various boxes with SATA drives (2.5", mSATA and DOM) > =========================== > - Emphase D1VHSD001G0 (DOM) 2 GB SLC > Write Cache: enabled > > - Emphase FD2510SI8G (2.5") 8 GB SLC > Write Cache: disabled (not setable) > > - WDC SSD-M0004S-7100 (mSATA) 4 GB SLC > Write Cache: enabled > > - ADATA SP600 (2.5") 32 GB MLC > Write Cache: enabled > =========================== > > And sure enough if I do a > $ echo "Testing..." > /mnt/kd/test > > and pull the power plug, the /mnt/kd/test file does not exist on reboot. And > before anyone asks :-) a journeled ext3 filesystem does not help here since > the new "data" is only in the drive's volatile RAM. > > The "write cache" does increase write performance, and for a general > computer, database, etc. this is desired. But, for the case of AstLinux I'm > not sure if this extra performance gain is needed. > > There are a few solutions: > > 1) Use an Uninterruptible Power Supply (UPS). Personally I do this by using > an inexpensive UPS supplying battery backup to the AstLinux box, cable modem > and main ethernet switch. AstLinux monitors the UPS status. > > 2) Use SSD's that default to "Write Cache: disabled" (rarely found) or have a > "Host Power Loss Protection" as with: > http://www.logicsupply.com/components/storage/solid-state-drives-ssd/q6mp6g030-2/ > > 3) Set "Write Cache: disabled" at startup for such afflicted drives. > > Solutions 1 and 2 are self explanatory, so let's discuss 3... > > As far as I know, the "hdparm" command is the only way to disable the drive's > write cache. I can't find a kernel driver option or kernel command line > option to do that. > > AstLinux uses the Busybox version of hdparm, and as such the following code > seems like a fairly safe way to disable the write cache: > -- > DRIVE="$(findfs LABEL=RUNNIX)" > DRIVE="${DRIVE%[0-9]}" > if [ -n "$DRIVE" ]; then > if hdparm -I "$DRIVE" 2>/dev/null | grep -q -i > '^[[:space:]]*[*][[:space:]]*write cache[[:space:]]*$'; then > if hdparm -W0 "$DRIVE" >/dev/null; then > echo "Disabled write cache for drive: $DRIVE" > fi > fi > fi > -- > Now, using the hdparm command should not be taken lightly, and you might ask > what happens to any active cache when the "hdparm -W0 ..." is issued, good > question. Some possibilities are: > > 1) Do it early enough on boot before data writes occur. > > 2) Some SSD firmware will do the correct thing. > > 3) Try to flush any active cache. > > The Busybox version of hdparm has code to automatically flush the cache when > a "hdparm -W0 ..." is issued, but is disabled in all versions of Busybox... > -- > #undef DO_FLUSHCACHE /* under construction: force cache flush on > -W0 */ > -- > No doubt there is a general problem with doing this. > > So, what should we do in AstLinux ? If anything. > All comments welcomed. > > Lonnie > > > > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > Astlinux-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > [email protected]. > > ------------------------------------------------------------------------------ _______________________________________________ Astlinux-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to [email protected].
