On Apr 1, 2011, at 23:35, Matthew Dillon wrote: > The solution to this first item is for the OS/filesystem to issue a > disk flush command to the drive at appropriate times. If I recall the > ZFS implementation in FreeBSD *DOES* do this for transaction groups, > which guarantees that a prior transaction group is fully synced before > a new ones starts running (HAMMER in DragonFly also does this). > (Just getting an 'ack' from the write transaction over the SATA bus only > means the data made it to the drive's cache, not that it made it to > the platter).
It should also be noted that some drives ignore or lie about these flush commands: i.e., they say they flushed the buffers but did not in fact do so. This is sometimes done on cheap SATA drives, but also on expensive SANS. If the former's case it's often to help with benchmark numbers. In the latter's case, it's usually okay because the buffers are actually NVRAM, and so are safe across power cycles. There are also some USB-to-SATA chipsets that don't handle flush commands and simply ACK them without passing them to the drive, so yanking a drive can cause problems. There has been quite a bit of discussion on the zfs-discuss list on this topic of the years, especially when it comes to (consumer) SSDs. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
