> > And the 520 doesn't claim this feature (look for "enhanced power loss > > protection" at http://ark.intel.com/products/66248), so that wouldn't > > explain these results anyway. > > Correct i think intel simply ignores CMD_FLUSH on that drive - no idea > why an they fixed this for their 330, 530, DC S3500 (all tested) You are not as I read the standard allowed to "ignore" it. In fact if you advertise the property you are obliged to implement it. The late Andre Hedrick made sure the standard was phrased the way it was to stop it being abused for benchmarketing. The goal was that anyone cheating would be non-compliant. Now its entirely possible to do clever stuff and treat it merely as a write barrier, providing you can't lose what is queued up. What the actual drives do I don't know.. all deep magic and not my department. A second thing to be careful about is that certain kinds of I/O barriers and atomic write patterns that force lots of commits to flash and erase cycles are going to wear the drive out faster and I've been told by manufacturers that drives do respond to such patterns by limiting the transaction rate in self defence (and presumably in the hope the OS will then begin to block stuff up better). Pavel - what is lost/kept over the reset of a device is also fairly clearly defined in the standard. Much is lost because if you committed a permanent configuration change that the controller couldnt support you would be a bit screwed! If you are driving an SSD I'd work very hard to avoid the need for any kind of O_SYNC or O_DSYNC type behaviour for exactly the same reason you avoid uncached memory accesses - the hardware can't do its job properly without the needed freedom. Use minimal barriers and proper sync points and your performance will be far higher. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
